User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.0 Safari/537.36 Build ID: 20150702232110 Steps to reproduce: 1) open firefox 2) type data below into address bar then press key "enter" data:script;base64,PGh0bWw+PHNjcmlwdD5hbGVydCgveHNzLyk8L3NjcmlwdD4gPC9odG1sPg== 3) js code: alert(/xss/) will be called in firefox in fact, the base64 string can be any js code Actual results: can run any js code, which will result in XSS,Fishing attack, and is dangrous to end user. Expected results: js code should not run, the same string input into Chrome, will just show the js code

It is a function of Firefox, but the "function" is unsafe. with the help of url redirection vul, we need not manually enter the data to exploit this vul.

This has nothing to do with the JS engine. Consider: data:text/html;base64,PGh0bWw+PHNjcmlwdD5hbGVydCgveHNzLyk8L3NjcmlwdD4gPC9odG1sPg== The only real issue here is why "data:script,<h1>Am I HTML?</h1>" is treated as HTML.

So nsDataChannel::OpenContentStream does nsDataHandler::ParseURI and gets back "script" as the type. Then it calls SetContentType, which lands in nsBaseChannel::SetContentType. This calls net_ParseContentType which calls net_ParseMediaType which will output nothing useful if the type does not contain '/'. So this is treated as an nsBaseChannel with empty type and ends up doing data-based content sniffing.

And just for curiosity, if the content type is correct (say application/javascript or text/javascript or so), are there any security checks we don't do in case it's just a bogus?

I'm not sure what security checks we'd need to do. If the content-type is text/javascript then we treat it just like we treat text/plain: we show the text.

So, if the mime type in the example from comment 0 is changed to text/html we behave the same way as if there were any bogus mime type. Doing security decisions based on mime type is definitely not the way. Hence, if there is any potential for an attack with a spoofed mime type, we definitely prevent loading the content by different mechanisms like an origin checking. Only way to exploit this is IMO a badly configured script/server that could be adding bogus mime types (in trust it cannot be executed) to data: which can carry any unescaped user content. Based on that this seems to me as an ordinary web side XSS that we cannot do much around. This particular one is just even harder to exploit.

(Just a note I sadly am not any security expert)

There does seem to be a bug here, but this doesn't pose any additional security risk. Anyone who could sneak in an attack with a data:bogus,xxxxxxxx URL could just use a real mime type that would be interpreted as would be useful in the attack. There is a difference in behavior of data: URLs between Firefox and other browsers that makes data: URLs more dangerous (and more useful) for websites visited with Firefox. Firefox is compliant with the HTML5 spec, but we have bugs on file to instead match other browsers. In any event, the security risks of that behavior are well documented.

Given what Chrome is doing I think we should treat MIME types that cannot be parsed as "text/plain;charset=US-ASCII" (the data: URL default, mostly for worse). (Safari TP instead passes the bit before the comma straight to the Content-Type header field value, typically resulting in a download for unknown MIME types, but that doesn't seem great either and ends up generating lots of invalid Content-Type header field values.)

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258