Re: [whatwg] Stricter data URL policy
On Wed, 9 Jul 2014, Jonas Sicking wrote: But javascript: is sort of screwed no matter what. A javascript URL inheritely will run javascript, and it always does so in the origin of whoever set the url. So pages will have to look for javascript: anytime they are handling URLs. But it's better if pages only have to look for javascript: when handling URLs. Rather than having to look for javascript:, data:, blob: and nextbigthing:. I'd love to simply deprecate javascript:. It doesn't seem like the use cases are worth the complexity for both implementations and authors. But I think it's too commonly used these days to get rid of. At least for quite some time. About 100x the usage of sync XHR if [1] means that I guess it means. Note that 'javascript:' at this point is about as deprecated as I think we can get it. It's just special-cased logic in the navigation algorithm. Everywhere else, it just gets treated as an unknown URL scheme. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stricter data URL policy
On Thu, Jul 3, 2014 at 10:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jun 3, 2014 at 12:21 AM, Jonas Sicking jo...@sicking.cc wrote: srcdoc is like eval(). Yes, it's definitely a tool that enables you to run 3rd party code in your own context and with your own principal. However whenever you use the feature you (should) know that it's running code in your own context and with your own principal. So hopefully pages will make sure to not pass untrusted 3rd party code to neither srcdoc nor eval(). We've seen this happen internally in Gecko where chrome code will get XSSed by being tricked to load data URLs. And I've been trying to move us towards only allowing data: to run with a chrome principal if chrome code explicitly opts in to that. I don't see why websites wouldn't face the same challenges and why the same solution wouldn't work there. What about: iframe src=javascript:alert(top.document.title)/iframe It seems that has the same issue. Yes, it has the same issue. But javascript: is sort of screwed no matter what. A javascript URL inheritely will run javascript, and it always does so in the origin of whoever set the url. So pages will have to look for javascript: anytime they are handling URLs. But it's better if pages only have to look for javascript: when handling URLs. Rather than having to look for javascript:, data:, blob: and nextbigthing:. I'd love to simply deprecate javascript:. It doesn't seem like the use cases are worth the complexity for both implementations and authors. But I think it's too commonly used these days to get rid of. At least for quite some time. About 100x the usage of sync XHR if [1] means that I guess it means. [1] http://www.chromestatus.com/metrics/feature/popularity#ReplaceDocumentViaJavaScriptURL / Jonas
Re: [whatwg] Stricter data URL policy
On Tue, Jun 3, 2014 at 12:21 AM, Jonas Sicking jo...@sicking.cc wrote: srcdoc is like eval(). Yes, it's definitely a tool that enables you to run 3rd party code in your own context and with your own principal. However whenever you use the feature you (should) know that it's running code in your own context and with your own principal. So hopefully pages will make sure to not pass untrusted 3rd party code to neither srcdoc nor eval(). We've seen this happen internally in Gecko where chrome code will get XSSed by being tricked to load data URLs. And I've been trying to move us towards only allowing data: to run with a chrome principal if chrome code explicitly opts in to that. I don't see why websites wouldn't face the same challenges and why the same solution wouldn't work there. What about: iframe src=javascript:alert(top.document.title)/iframe It seems that has the same issue. -- http://annevankesteren.nl/
Re: [whatwg] Stricter data URL policy
On Mon, Jun 2, 2014 at 11:19 AM, Anne van Kesteren ann...@annevk.nl wrote: Workers might be harder as there might be content relying on workers working with data URLs. That needs to be investigated. Per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3046 (thanks Simon) workers throw in Chrome when constructed from a data URL so it seems like we have an opportunity there. -- http://annevankesteren.nl/
Re: [whatwg] Stricter data URL policy
On 6/2/14, 5:19 AM, Anne van Kesteren wrote: This is not the case in Chrome and we'd like this to be no longer the case in Gecko. Note that it's not clear to me what we means in this case. For example, I'm unconvinced we want to change Gecko behavior here. And then it would only be set for the initial fetch, not after the iframe has been navigated. More precisely, it would be set for loads due to the iframe's src changing but not ones due to link clicks and location changes? Or do you really mean only for the initial fetch and not later changes to @src? I'll be updating Fetch shortly with this new policy This seems fine, since we want it no matter what; the only disagreement is about when that flag should be set, right? -Boris
Re: [whatwg] Stricter data URL policy
On Mon, Jun 2, 2014 at 2:48 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/2/14, 5:19 AM, Anne van Kesteren wrote: This is not the case in Chrome and we'd like this to be no longer the case in Gecko. Note that it's not clear to me what we means in this case. For example, I'm unconvinced we want to change Gecko behavior here. You're not persuaded by the attack scenario? And then it would only be set for the initial fetch, not after the iframe has been navigated. More precisely, it would be set for loads due to the iframe's src changing but not ones due to link clicks and location changes? Or do you really mean only for the initial fetch and not later changes to @src? Actual changes to @src seems fine since they are under the control of the page. (At least as much as the allowsameorigindataurl attribute.) I'll be updating Fetch shortly with this new policy This seems fine, since we want it no matter what; the only disagreement is about when that flag should be set, right? Provided we agree that it is always unset after any redirect, yes. -- http://annevankesteren.nl/
Re: [whatwg] Stricter data URL policy
On 6/2/14, 9:00 AM, Anne van Kesteren wrote: You're not persuaded by the attack scenario? Correct. I mean, the same scenario applies to srcdoc, document.write() into an iframe, etc. Why are data urls special? Provided we agree that it is always unset after any redirect, yes. We agree on that. -Boris
Re: [whatwg] Stricter data URL policy
On Mon, Jun 2, 2014 at 3:03 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/2/14, 9:00 AM, Anne van Kesteren wrote: You're not persuaded by the attack scenario? Correct. I mean, the same scenario applies to srcdoc, document.write() into an iframe, etc. Why are data urls special? The attack is the URL. A developer has to specifically consider data URLs and realize their implications. Other URLs will do the right thing and not run potentially hostile code stealing same-origin data. Provided we agree that it is always unset after any redirect, yes. We agree on that. Great! -- http://annevankesteren.nl/
Re: [whatwg] Stricter data URL policy
On 6/2/14, 10:15 AM, Anne van Kesteren wrote: The attack is the URL. A developer has to specifically consider data URLs and realize their implications. Note that this is already true for javascript: URLs in @src values (but not in location sets and the like, I agree). -Boris
Re: [whatwg] Stricter data URL policy
On Mon, 2 Jun 2014, Anne van Kesteren wrote: At the moment data URLs inherit the origin of the context that fetches them. To be precise, the origin of data: URLs themselves is the unique origin. It's the origin of resources that come from data: URLs that's different. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stricter data URL policy
On Mon, Jun 2, 2014 at 6:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/2/14, 9:00 AM, Anne van Kesteren wrote: You're not persuaded by the attack scenario? Correct. I mean, the same scenario applies to srcdoc, document.write() into an iframe, etc. Why are data urls special? srcdoc is like eval(). Yes, it's definitely a tool that enables you to run 3rd party code in your own context and with your own principal. However whenever you use the feature you (should) know that it's running code in your own context and with your own principal. So hopefully pages will make sure to not pass untrusted 3rd party code to neither srcdoc nor eval(). We've seen this happen internally in Gecko where chrome code will get XSSed by being tricked to load data URLs. And I've been trying to move us towards only allowing data: to run with a chrome principal if chrome code explicitly opts in to that. I don't see why websites wouldn't face the same challenges and why the same solution wouldn't work there. / Jonas
