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?

Improve this question
4
  • 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
    Commented Dec 11, 2015 at 8:46
  • will it work even with content-type is application/JSON in response ? I don't think so .
    – avicoder
    Commented Dec 11, 2015 at 9: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
    Commented Dec 11, 2015 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
    Commented Dec 11, 2015 at 10:43

1 Answer 1

Reset to default
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.

Improve this answer
4
  • 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
    Commented Dec 11, 2015 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
    Commented Dec 11, 2015 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
    Commented Dec 11, 2015 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 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
    Commented Dec 12, 2015 at 8:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .