[Owasp-boston] Extend html5 “Access-Control-Allow-Origin” ?
brad.edmondson at gmail.com
Tue Feb 22 15:29:58 EST 2011
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
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.
More information about the Owasp-boston