ASP.NET Web API and potential XSS

Question

I'm wondering if my ASP.NET Web API had an XSS vulnerability as my controller didn't have a method to handle the default GET call.

Without the GET method being handled in the code a call to
/api/mycontroller/?<script>alert('hi');</script> would result in:

{"Message":"No HTTP resource was found that matches the request URI
 'http://localhost:8888/api/mycontroller/?'.",
 "MessageDetail":"No action was found on the controller 'MyController' that 
  matches the request."}

Note that the script tags are in the JSON source, they're just not displayed on the page.

Drop the question mark, /api/mycontroller/<script>alert('hi');</script>, and you'll get
"A potentially dangerous Request.Path value was detected from the client (<)." so now an HttpException is protecting the users.

The API's routing is simply the default one:

.Routes.MapHttpRoute(
    "DefaultApi", 
    "api/{controller}/{id}", 
    new { id = RouteParameter.Optional });

and I've now added in a default action method:

[HttpGet]
public HttpResponseMessage Get()
{ 
    // do something. 
}

Putting in this action method, however, could easily be missed when a developer is creating an API, I think.

So I was wondering, is this an exploitable XSS issue?

Answer 1

This condition was probably not an exploitable XSS vulnerability for most applications. This is more likely a "defense in depth" filter to prevent programmers from unintentionally causing problems.

XSS is solved in an API's by setting the content-type to application/xml or application/json depending on the return data type (and text/plain is also commonly used to prevent XSS). Reflective and Persistent XSS can only be a problem if the page has an HTML content type. DOM based XSS is still a concern for web services. The Content-Security Policy can be used to further restrict the ability to execute JavaScript using HTML injection, and is useful in preventing DOM-based XSS.

When using a modern browser, an XSS payload shouldn't execute on a non-executablite content type. Never the less, it is a good idea to explicitly disable content sniffing for legacy or non-standard browsers:

X-Content-Type-Options: nosniff