[Owasp-boston] Extend html5 “Access-Control-Allow-Origin” ?

Brad Edmondson brad.edmondson at gmail.com
Sun Feb 27 16:24:27 EST 2011


For those inclined to keep score, I was pretty late to the game with
this idea. Mozilla has already proposed Content Security Policy (CSP),
which addresses everything I mentioned and more. It includes more than
ten policy directives allowing whitelisting for all kinds of resource
URIs. It even has a JSON-based XSS reporting capability like that
which I mentioned in my point 3. I'm a little embarrassed I didn't
find these resources before coming to the list:

http://people.mozilla.com/~bsterne/content-security-policy/index.html
https://wiki.mozilla.org/Security/CSP
https://developer.mozilla.org/en/Security/CSP/CSP_policy_directives
https://developer.mozilla.org/en/Introducing_Content_Security_Policy
http://www.w3.org/2010/07/appsecwg-charter#deliverables

Per link 4, Firefox 4 (and gecko 2.0) supports/will support CSP. Per
link 5, W3 is developing a working group to consider formalizing this
and other appsec issues.


Best,
Brad

On Tue, Feb 22, 2011 at 15:29, Brad Edmondson <brad.edmondson at gmail.com> wrote:
> Hi all-
> Since attending OWASP Boston in November, I have been wondering if we
> are missing an opportunity to try and define an access-control header
> that can do more to combat xss.
>
>
> Specifically, access-control-allow-origin seems limited in scope
> primarily to xmlhttprequest, or at most to a DOM object (though if I
> am reading this spec incorrectly, call me out  :-). It also seems to
> be focused on incoming xsrf, and to leave outgoing xss alone. Perhaps
> another header, with two modifications, might make it much easier to
> contain outbound xss. It could:
>
> 1) allow a page to provide a whitelist of authorized URIs which the
> page's DOM may request (the whole DOM, not just a particular object).
>
> For example, "access-control-authorized-request-uri" could define an
> 'origin list' of URIs that the page might possibly request. Any
> request the DOM makes outside this origin list would be considered
> malicious and would be dropped by the browser. This would allow
> secure.banksite.com to make a promise to the browser that its pages
> will never, ever request anything from anywhere other than
> secure.banksite.com, www.banksite.com, and banksite.affiliate.cdn.com
>
> 2) extend the origin controls granted to xmlhttprequest via
> "access-control-allow-origin", and to flash via "allow-access-from,"
> and to other individual object types, UP one level to the entire page
>
> 3) allow browsers to report requests outside of this whitelist back to
> the originating server
>
> This is half in jest, but half serious: a browser could automatically
> issue another http request indicating the problem URIs whenever a page
> tells it to make a request outside its whitelist. This would allow
> site administrators to detect xss, or (more often?) misconfigured URI
> whitelists.
>
> 4) be optional; like Access-Control-Allow-Origin, would be optional
> and would default to allow-all
>
> 5) not apply to traditional hyperlinks, unless the DOM contrives to
> execute them - HTTP referer links would be left alone
>
>
> What does everyone think? I am relatively new to OWASP and to web app
> sec, but I haven't been able to think myself out of the belief that we
> need something like this. It seems somewhat analogous to memory
> randomization for compiled code, in that it doesn't combat the root
> cause of insecure code, but it can offer a relatively low-cost control
> to which applications could opt-in. And in that many applications seem
> to be hurting without it.
>
> All comment and thoughts are welcome.
>
> Best,
> Brad
>


More information about the Owasp-boston mailing list