This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html Multipage: http://www.whatwg.org/C#sandboxOrigin Complete: http://www.whatwg.org/c#sandboxOrigin Comment: Data URLs should not inherit the origin after a redirect. Posted from: 207.218.72.65 by annevk@annevk.nl User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0
Consider a cross-origin URL that redirects to a same-origin URL open redirector. The cross-origin URL can cause the same-origin URL redirector to output a data URL that might harm the site in question. I hope to clarify this in Fetch too, but updating HTML meanwhile might be good.
Note that in Gecko, redirects to a data: URL do not in fact inherit any origins, last I checked.
As far as I can tell, the spec already says that. Specifically, it has this entry: If a Document was generated from a data: URL that was returned as the location of an HTTP redirect (or equivalent in other protocols) The origin is an alias to the origin of the URL that redirected to the data: URL. Anne: Am I missing something?
This is a bug about having it NOT be an alias and instead having it be a new uniquer origin, as far as I can tell.
Indeed. Also, that does not address the case for <img>, <script>, and other sources that take a data URL.
Oh, I see. Yeah, that seems reasonable.
Aren't <img> and <script> already handled by the potentially-CORS logic?
Checked in as WHATWG revision r7881. Check-in comment: Security: data: URLs shouldn't get the origin of a redirector, since that redirector might be tricked into redirecting a data: URLs by a hostile origin, thus letting that hostile origin expose a same-origin data: URL. http://html5.org/tools/web-apps-tracker?from=7880&to=7881
I've only done the definition for Documents. Let me know if I need to do more, I couldn't work out what you meant for <img> etc.
I think the question is what happens if you have a cross-origin image load that redirects to a data URL. And the answer is that the resulting image should NOT be considered same-origin with the linking document for things like canvas tainting and whatnot. As long as this is what happens now, we're good.
Well as soon as you go cross-origin, it ends up not being same-origin, so I don't think the problem occurs. (Only way I guess it could occur is if the CORS headers from the redirect somehow applied to the data: URL, but I don't think that happens. If it does, it'd be a bug in CORS, not HTML.)
Do we want same-origin -> data URLs to be considered same-origin though? I thought that was a case we did not want to allow.
Why would we not want to allow it?
The one I see is a page that allows pasting in same-origin links that open in an <iframe> of sorts and they also have an open-re-director going.
I don't think I've ever seen such a page, but I dunno... Do you have an example?
(It would have to be a page that does that, but still blocks direct data: URLs.)
For Documents, even same-origin redirects to data: end up with a unique origin. For images, we're already treating them specially in HTML, and the fetch spec is taking that over anyway. I think we're done here. Reopen if I missed something.