- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 6 Dec 2009 13:59:40 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Maciej Stachowiak <mjs@apple.com>, Ian Hickson <ian@hixie.ch>, "sird@rckc.at" <sird@rckc.at>, public-web-security@w3.org
On Sun, Dec 6, 2009 at 1:47 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > Gecko has used the "parent" origin for data: URIs at least since mozilla bug > 31818 was fixed in June 2000. > > [...] > > We do happen to think that this behavior is secure, and reasonably > implementable. It does have a gotcha for website developers, however: if > they allow user-contributed <iframe> or <object> elements and don't vet the > "src" and "data" attribute, respectively, it allows the user to inject > scriptable content into the page's origin... I happen to think that not > vetting @src and @data is a problem in any case, but apparently some people > don't do it. In some sense, a site needs to vet all URLs for javascript URLs, but this behavior means that every time you see "javascript:" in an XSS filter, they're probably insecure unless you also see "data:" right next door. (By the way, I'd imagine data URLs in a@href is a more common XSS hole than iframe@src.) I don't think anyone would argue that javascript URLs impose large security costs, they just happen to be very, very useful. The question is whether inheriting the security context for data URLs is sufficiently useful to justify the security costs. The sad part is that the standoff restrains sites from realizing the benefits of privilege inheritance because they can't rely on it working on Safari, but Firefox users continue to bear the security costs. Adam
Received on Sunday, 6 December 2009 22:06:12 UTC