JSON API response flagged as XSS by vulnerability scanner. Is this a false positive?

Question

When a user attempts to access any URL without authentication (including a non-existent URL), my web service returns an HTTP 401 response. This response is JSON encoded, and the body of this response contains the path requested by the user, presumably for diagnostic purposes. The response also includes the www-authenticate header. If a user visits this URL in the browser, this triggers their browser to ask for credentials.

However, automated scanning tools report that this is an XSS vulnerability. This appears to be because the requested path is included, and if the requested path also happens to be valid JavaScript, this path is returned along with the response. See cURL output below:

curl -i  'https://myservice.example.com/<script>alert(1)</script>'
HTTP/2 401
server: nginx
date: Tue, 19 May 2020 15:02:20 GMT
content-type: application/json;charset=UTF-8
content-length: 167
strict-transport-security: max-age=31536000 ; includeSubDomains
www-authenticate: Basic realm="Spring"

{"timestamp":1589900540080,"status":401,"error":"Unauthorized","message":"Full authentication is required to access this resource","path":"/<script>alert(1)</script>"}%

I think that this is a false positive, as the API response is JSON encoded, as per this question: Reflected XSS via JSON executed with Burp, but how to do it in realistic conditions?

Am I correct?

Answer 1

This isn't vulnerable to XSS since the Content-Type is set to application/json and thus no Javascript will be executed by all major modern browsers. If you do some fancy Javascript stuff with the JSON response, it could become a DOM XSS (but this doesn't seem to be the case here from what you shared).

A more detailed answer can be found here.

Answer 2

An XSS vulnerability usually consists of two components: A backend which reflects user-provided strings without filtering them and a frontend which puts that input into a HTML document without filtering it.

So you don't just need to look at what the server does, you also need to look at the application which consumes that JSON response.

Is there a possibility that it will inject the path into a HTML document as-is without escaping any HTML tags in it first? Or that it processes that JSON document not with JSON.parse but with eval which would allow the server to pass exectuable code to it?

If that's the case, then the first priority would be to fix the consuming application. But as part of a defense-in-depth strategy you would also be well-advised from preventing the server from passing strings which contain valid HTML to the client. A good approach is to encode < and > as < and >.

Also make sure that the JSON response doesn't get malformed if the user-provided string contains a ". That might not just be annoying, it could also be abused in some scenarios to confuse the tools which consume the response.

Answer 3

This looks like a finding that many automated scanners will find: they put something in the URL and see it reflected back in the response body.

In your case, this is reported back in valid JSON and therefor this is not an issue. While not clean as a whistle, you'll be hard pressed to find a browser or API consumer that fails on the text in there. For all you know, that dangerous looking HTML could be valid and it's up to the client to deal with that well.

Not so much in a text/html context, there's a case for this in that scenario.

Answer 4

As it is right now, no. All that has happened is a client placed a bespoke string in a JSON response. For XSS to occur, a bespoke string must be written to an unsafe resource (an HTML file).

If you have a webpage which for whatever reason prints the path of this request (maybe a request logging page), you could have something nasty. For example, this code is vulnerable:

.
.
.
output.Append($"<tr><td>{request.path}</td></tr>\n");
.
.
return Ok(output.ToString());

Now this is an unrealistic example, because typically if you're using C# like in this example, you do not generate markup like this, you would use Razor, or generate it on the front end with AJAX. I chose this example because it's concise and more likely to be understood if you yourself are not a .NET programmer.

XSS and most injections can be prevented in two ways. You can escape (aka sanitize) every string. For you that means replacing < and > with < and >. Or you can make sure that unsafe strings are never treated as code (or in this case, markup). Many front ends, such as React go for the second option.

If you use React and have JSX like this:

.
.
.
return <h1>{foo}</h1>

No matter the contents of the variable foo, it will never be treated as markup/code unless you do this:

.
.
.
return <h1 dangerouslySetInnerHTML={{_html : foo}}/>

You'll have to choose one option, it's probably easier to sanitize the string unless you're already using React or something similar. It is easier to sanitize the string in the API because that way you know everything that uses it is safe, however, that may not necessarily be the most appropriate stylistically: you may feel that the sanitization of strings is not an API issue but an issue for whatever uses the API to solve.