4

I just come across one of the customer's website for penetration testing having JSON callback reflecting the user input in the response body.

like this:

https://example.com/somepage?callback=<wow>mypayload

{"callback":"mypayload"}

As content-type is application/JSON therefore browser is not parsing the HTML tags and also X-Content-Type-Options=nosniff" is not set in the response header.

Is is possible to create a exploitable payload which result in XSS or other kind of vulnerability?

avicoder
  • 313
  • 2
  • 11
  • 2
    Depends on what the client side code does with the response. If it does something like `document.write(callback)` (or a dom based equivalent), sure. As it stands, it's impossible to say. – Matthew Dec 11 '15 at 08:46
  • will it work even with content-type is application/JSON in response ? I don't think so . – avicoder Dec 11 '15 at 09:26
  • 1
    If you dump the contents of a JSON string into your page, without escaping, whatever is there will be dumped into the page. Doesn't matter what the content type is - the browser will respect the content type, but your code can ignore it. Natively, you won't be able to do anything - as you say, the browser isn't parsing it as HTML. Your code is free to carry out its own parsing though. – Matthew Dec 11 '15 at 10:34
  • 1
    It would be hard to tell how it would be exploitable at all without more information. If the content type is JSON, then the browser should read it as text, so you probably can't get anywhere directly. If a page that is using it is exploitable and allows you to arbitrarily set those URL parameters, and that ends up getting used by that page, then maybe. Again, depends on the implementation. – Jonathan Gray Dec 11 '15 at 10:43

1 Answers1

3

Content-Type is just a suggestion of the data provided to the receiver (consumer). This means that the receiver may or may not take action based on that header.

A typical browser will read the content type header to render the content in the best possible way (JSON as a tree, audio stream as a player, etc.). Try to send a JSON string to a browser with Content-Type: application/json and without. Same payload received, different presentation.

A generic application will do whatever it wants with the content. In particular it may decide to display it (or parts of) as raw HTML. In that case if your payload includes correctly formatted JavaScript, it will be executed.

This is not different from classical application hardening. The golden rule is never trust anything you receive. This includes not only the body of your HTTP query but also the headers.

As a side note, the malicious content can get to your data not only though what you receive and process. Someone can also modify, for instance, the data which is stored in your DB directly in the DB. Thus the absolute need to escape what is sent to the recipient, which is ultimately how XSS (and similar) attacks are performed.

WoJ
  • 8,957
  • 2
  • 32
  • 51
  • If someone can modify your database contents directly, with no control over what's edited, I think you're hosed at that point. If you can't trust the data in your database, there's a huge number of exploits possible. – Steve Sether Dec 11 '15 at 16:48
  • One can have an injection, it may be modified through another app, whatever. The point I want to make is that the threat can come from several places and that what is sent to the user must be sanitized (not relying on some kind of input filtering). And yes, if the database is vulnerable there are also other problems on the horizon. – WoJ Dec 11 '15 at 21:26
  • I think it's fine to have another layer that checks the input because nothing is ever 100%, and you'd be protecting against any input validation that wasn't correct. My point is that if you have an injection attack, you can't really protect against that in any meaningful way. It's like trying to protect against someone gaining root on your system – Steve Sether Dec 11 '15 at 21:50
  • Yes, agreed, checking input is fine but it must not be the only way to protect against XSS (although it is often easier to implement than output escaping). If you look at the [OWASP XSS Prevention Cheat Sheet](https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet) you see that input measures vs output measures are 1:5. This said, as you mention, if the DB is compromised one *may* have the problem of data integrity/confidentaility. It is just a *may*, however, as the malicious payload may have been injected for reuse via an XSS. – WoJ Dec 12 '15 at 08:35