6

Background information
- Application responds to request to a particular URL with content-type: application/json

  • JSON response contains a parameter from the request
  • Escapes the quote with a slash
  • Doesn't do an eval on response
  • Responds to requests which do not have X-Requested-With: XMLHttpRequest (i.e. if you directly paste the URL with parameters in the address bar)

Question:

Is there a way to do a successful XSS on the application?

Please feel free to edit the question if it is not clear

Sachin Kumar
  • 820
  • 3
  • 9
  • 14
  • If you could also put reason for vote down in comments, that would really help in improving my questions in future. Thanks – Sachin Kumar Apr 16 '12 at 16:34
  • A good article about exploiting XSS in application/json response could be find at http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html – user1829087 Sep 19 '14 at 17:14

3 Answers3

4

Dom based XSS is still possible. In this case your JavaScript could be writing unsanitized output to the page.

There are other security concerns with this design.

I would make sure that your API does not respond to requests that lack the X-Requested-With: XMLHttpRequest header. This is because you still have to address json data theft as well as CSRF. It should be noted that in both json data theft as well as csrf the request isn't being made with an XHR, so checking X-Requested-With: XMLHttpRequest would be a valid defense. Checking the HTTP Referer can also be used to mitigate both of these attacks.

If you require authentication to access all or part of this JSON api then you need to use HTTPS, or you will be in violation of owasp a9

Community
  • 1
rook
  • 46,916
  • 10
  • 92
  • 181
  • Good points. (Un)Fortunately application is not writing the response to body or to any DOM element. User input is coming back in case of error message so the call back method just doesn't do anything with it . – Sachin Kumar Apr 16 '12 at 16:36
  • Some excellent points here. However, I do not recommend relying upon the HTTP Referer header. Also, I don't think CSRF is a risk here, because requesting the JSON data is a side-effect-free operation (a GET request). – D.W. Apr 16 '12 at 19:29
  • @D.W. I am not aware of the details of this api the OP was sparse. However, I disagree in the http referer part, an HTTP referer check is being used to prevent the CSRF vulnerability with the highest severity metric. (Motorolla Surfboard Cable modem DoS) – rook Apr 16 '12 at 19:41
  • @Rook, "an HTTP referer check is being used to prevent the CSRF" - sorry, I can't make head or tails of what you are trying to say here. I do know that some sites use the Referer header this way. I'm just saying it is not a good defense, from a security perspective, regardless of how many people do or don't use it. – D.W. Apr 16 '12 at 21:53
  • @D.W. well I did link to the CSRF prevention cheat sheet... You could also try reading Mozilla's "Origin" http header proposal. – rook Apr 16 '12 at 21:55
3

If I can make some assumptions (see below), this seems fine on modern browsers. I do not know of any XSS vulnerabilities.

Assumptions:

  1. The untrusted data (from the URL parameter) is only inserted into a quoted JSON value context, never anywhere else. It is not inserted in as an unquoted value. It is not inserted into a key.

  2. The server does not perform any side effects or other actions, when you request the JSON data. (This means you don't need to worry about CSRF attacks.)

  3. There is no confidential data anywhere in this JSON data structure. (Not relevant for XSS, but relevant to JSON data theft, as @Rook explains.)

  4. The application does not have any client-side XSS vulnerabilities (aka DOM-based XSS).

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • I have the same thoughts. Lets wait if someone wants to counter this, otherwise I will mark this as the right answer – Sachin Kumar Apr 17 '12 at 08:34
2

One thing to think about is in IE the content-type can and will be ignored if the browser sniffs the first few lines of text and determines it to look like html. We run into this all the time. So, if for example you have some json but in that response i can get in HTML tags. The browser will see this and say oh I see I think this should be HTML. At that point the payload would execute. Even if the content-type was not text/html.

tyweed
  • 21
  • 1