Reflective XSS in script codes with Content Type "text/javascript"

Question

I have a webpage that returns raw script code with the headerContent-Type: text/javascript. However I found that there is a reflective xss in one of the parameters passed to the url which is copied into the returned javascript. This is the setup.

URL:

www.mysite.com/js?p1=data&p2=NodeFrame.jsResponse

Javascript:

/**/NodeFrame.jsResponse({"success":true,"data":{"id":0,"jdata":[]}});

Now the XSS I've come up with goes like this

URL:

www.mysite.com/js?p1=data&p2=NodeFrame.jsResponse({"success":true,"data":{"id":0,"jdata":[]}});alert(1);//

Javascript:

/**/NodeFrame.jsResponse({"success":true,"data":{"id":0,"jdata":[]}});alert(1);//({"success":true,"data":{"id":0,"jdata":[]}});

To make it clear, the values of parameter p2, is used unsanitized in the returned script, as the function name.

The HTTP response does have Content-Type: text/javascript, in it. And the script is not embedded within an html document.

Is there any chance that the code can be executed in a browser? I'm worried about old browsers and such basically. Assume that X-Content-Type-Options: nosniff is not set, is there any browser which will actually render it? If so can I get a PoC or a browser version to test?

Edit: The question is, will any version of any browser, sniff a raw script code with Content-Type: text/javascript header set, given that X-Content-Type-Options: nosniff is not set.

Answer 1

The question is, will any version of any browser, sniff a raw script code with Content-Type: text/javascript header set, given that X-Content-Type-Options: nosniff is not set.

For executing the script inside the browser it will not matter if the type is sniffed or not. If only the script itself is given to the browser, that is it is not embedded somehow into HTML, then the browser does not have a document where the script can run. That means the script will be displayed or downloaded but not executed within the context of an HTML document. If you use Internet Explorer it might also offer the script for execution, similar to other executable content. Some tests with IE11 show that it does not matter what the Content-Type is in this case, because either the data will be shown inline (text/plain, images) or it will be offered for download and maybe execute. If execution is offered seems to depend solely on the file extension and X-Content-Type-Options: nosniff seems to have no effect on this decision.

If the script is embedded or referenced from inside a HTML document the content-type mostly does not matter at all because the browser "knows" what the content must be (i.e. Javascript) and will usually ignore the Content-type set by the server anyway. Thus you can successfully deliver a Javascript file with a content-type of text/plain, application/octet-stream and even image/gif to most browsers. From the browsers I've checked a while ago only newer versions of Chrome will exclude some content-types, i.e. it is no longer possible to include script with a content-type of image/whatever into Chrome. It still works with other browsers.

Answer 2

First of all, text/javascript is outdated and, consequently, less reliable. The accepted official MIME type for JavaScript is application/javascript. Any of the major modern browsers should know how to handle the latter by not executing it when visited directly.

With regard to the security vulnerabilities present in Internet Explorer, JavaScript MIME types seem to be unaffected. In an article by Microsoft about MIME type detection, there are clearly defined recognized types, where JavaScript is nowhere present. This means that Internet Explorer will automatically use whatever is returned from the server:

If the "suggested" (server-provided) MIME type is unknown (not known and not ambiguous), FindMimeFromData immediately returns this MIME type as the final determination. The reason for this is that new MIME types are continually emerging, and these MIME types might have formats that are difficult to distinguish from the set of hard-coded MIME types for which tests exist.

Google Chrome tends to emphasize forward compatibility as well, so presumably, a similar process would occur.

Therefore, a script sent with Content-Type: application/javascript should not be vulnerable to type sniffing, but this does not mean that necessary precautions should not be taken to make sure that this does not happen. People may be using less reliable browsers or may view a file in a context other than a browser that does not correctly recognize MIME types.

It would be best to always use X-Content-Type-Options: nosniff since this case is exactly what it was designed for.

Answer 3

Old versions of IE will treat it , if you embeded it in a script tag it will be rendered and executed