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

Arthur Barstow afbarstow at gmail.com
Tue Feb 22 15:50:12 EST 2011

Brad - FYI, discussions related to the CORS spec [CORS] and this header
occur on the public-webapps at w3.org which is archived at [WebApps]. The W3C's
public-web-security at w3.org mail list [WebSec] has also been used for some
related discussions.

-Regards, Art Barstow

[CORS] http://dev.w3.org/2006/waf/access-control/
[WebApps] http://lists.w3.org/Archives/Public/public-webapps/
[WebSec] http://lists.w3.org/Archives/Public/public-web-security/

On Tue, Feb 22, 2011 at 3:29 PM, 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
> _______________________________________________
> Owasp-boston mailing list
> Owasp-boston at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-boston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-boston/attachments/20110222/e43e5856/attachment.html 

More information about the Owasp-boston mailing list