- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 07 Dec 2009 04:30:21 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, "sird@rckc.at" <sird@rckc.at>, public-web-security@w3.org
On Dec 6, 2009, at 1:59 PM, Adam Barth wrote: > > 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. For what it's worth, I don't think we ever made a conscious decision to make data: URLs a unique origin forever. We originally had a rule of literally granting the origin of the parent/opener. At the time we realized the security flaw, we didn't have much time to implement something complicated before the next Safari release. So we did the simple thing of unique origins instead of the more complicated thing required to grant the origin of the frame that initiated the load (the referrer rather than the parent, effectively). We considered doing the more complex model eventually. We also thought we were following the Firefox behavior at the time. Perhaps that was due to bad testing, given the bug Boris cited. Here is the changeset (including ChangeLog entries) where we made the change: <http://trac.webkit.org/changeset/24938>
Received on Monday, 7 December 2009 12:30:55 UTC