21506 2013-04-02 09:31:09 +0000 Data URLs should not inherit the origin after a redirect. 2013-09-12 20:16:05 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#sandboxOrigin P3 normal Unsorted 1 contributor ian annevk bzbarsky ian jonas mike contributor oldest_to_newest 85364 0 contributor 2013-04-02 09:31:09 +0000 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 85365 1 annevk 2013-04-02 09:33:15 +0000 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. 85390 2 bzbarsky 2013-04-02 14:46:05 +0000 Note that in Gecko, redirects to a data: URL do not in fact inherit any origins, last I checked. 85808 3 ian 2013-04-09 17:57:44 +0000 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? 85810 4 bzbarsky 2013-04-09 17:59:18 +0000 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. 85811 5 annevk 2013-04-09 18:12:38 +0000 Indeed. Also, that does not address the case for <img>, <script>, and other sources that take a data URL. 86018 6 ian 2013-04-12 06:58:15 +0000 Oh, I see. Yeah, that seems reasonable. 88525 7 ian 2013-05-31 20:12:27 +0000 Aren't <img> and <script> already handled by the potentially-CORS logic? 88526 8 contributor 2013-05-31 20:13:19 +0000 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 89194 9 ian 2013-06-12 19:06:07 +0000 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. 89262 10 bzbarsky 2013-06-13 15:53:03 +0000 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. 89420 11 ian 2013-06-17 22:17:52 +0000 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.) 89549 12 annevk 2013-06-19 06:11:13 +0000 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. 90153 13 ian 2013-07-02 22:01:38 +0000 Why would we not want to allow it? 91793 14 annevk 2013-08-08 13:59:08 +0000 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. 91807 15 ian 2013-08-08 22:07:08 +0000 I don't think I've ever seen such a page, but I dunno... Do you have an example? 91808 16 ian 2013-08-08 22:07:36 +0000 (It would have to be a page that does that, but still blocks direct data: URLs.) 93310 17 ian 2013-09-12 20:16:05 +0000 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.