The JSON Hijacking vulnerability in JSONP and its relationship with the csrf/xss vulnerability, hijackingxss

The JSON Hijacking vulnerability in JSONP and its relationship with the csrf/xss vulnerability, hijackingxss

I have been exposed to the so-called JSON Hijacking vulnerability during my internship, but recently I found that I did not understand it very well. It seems that I have some differences and connections with xss and csrf.

In-depth study of JSONP (JSON with Padding ).

The following paragraph intercepted from: http://stackoverflow.com/questions/2067472/what-is-jsonp-all-about carefully look at it is clearer.

Say you're on domain abc.com, and you want to make a request to domain xyz.com. To do so, you need to cross domain boundaries, a no-no in most of browserland.

The one item that bypasses this limitation is <script> tags. when you use a script tag, the domain limitation is ignored, but under normal circumstances, you can't really DO anything with the results, the script just gets evaluated.

Enter JSONP. when you make your request to a server that is JSONP enabled, you pass a special parameter that tells the server a little bit about your page. that way, the server is able to nicely wrap up its response in a way that your page can handle.

For example, say the server expects a parameter called "callback" to enable its JSONP capabilities. Then your request wocould look like:

http://www.xyz.com/sample.aspx?callback=mycallback

Without JSONP, this might return some basic JavaScript object, like so:

{ foo: 'bar' }

However, with JSONP, when the server has es the "callback" parameter, it wraps up the result a little differently, returning something like this:

mycallback({ foo: 'bar' });

As you can see, it will now invoke the method you specified. So, in your page, you define the callback function:

mycallback = function(data){  alert(data.foo);};

And now, when the script is loaded, it'll be evaluated, and your function will be executed. Voila, cross-domain requests!

Give a rough explanation. For example, there is such a section in abc.com <script src = "http://www.xyz.com/sample.aspx? Callback = mycallback "> </script>

Sample. aspx in xyz.com may be implemented as follows:

PHP Code

1 2 3 4 5 6

<? Php Header ('content-Type: text/html; charset = UTF-8 '); $ Callback = $ _ GET ['callback']; $ Data = "{foo: 'bar '}"; Echo $ callback. "(". $ data .");"; ?>

The returned result of the src tag request is <script> mycallback ({foo: 'bar'}); </script>, that is, the mycallback function is executed.

{Foo: 'bar'} is passed as a parameter to facilitate the next operation. Callback is only a key and can also be written as jsonp. Of course, the key obtained by the server must be changed.

Here, for normal requests, jsonp has no security issues. However, for some cgi that expose sensitive information such as user IDs and nicknames in the login state, we can directly access

Http://www.a.com/json.php? Mod = pay & func = openvip & callback = loginInfoCallback although we have not implemented loginInfoCallback, as mentioned above, the server will return

LoginInfoCallback ({"ret":-1102321, "data": {"_ id": 1032412, "_ nick": "jnusimba "}}); of course, this is because another tab in the browser of jnusimba has logged on to a.com.

. So the attack method is in a third-party site through the "<script src = http://www.a.com/json.php? Mod = pay & func = openvip & callback = loginInfoCallback> </script>"

You can obtain the ID and nickname of the current user in the loginInfoCallback parameter of the function.

The preceding JSON Hijacking vulnerability can be considered as a csrf vulnerability, that is, csrf write-read. The basic principle is that the browser's session mechanism is used when a third-party site requests a.com.

The cookie related to a.com is also sent. In terms of defense, it is better to verify the form token on the refer/request, that is, it has a value that cannot be predicted by a third party.

For the php code on the server above, the returned {foo: 'bar'} does not carry the login state information, so there is no real risk. But I don't know if someone notices it doesn't. It returns the header

Content-Type: text/html; that is, the type setting is incorrect. It should be content-Type: text/javascript; (or application/javascript) set to html format, which may cause xss attacks, ratio

For example, callback = <script> alert ('aaa') </script>, that is, the browser will pop up the box (note that xss attacks may be restricted in High-version ie and chrome versions, test in firefox ).

The following example shows a youku site that was dug up in the previous 10 days because of the reflection xss vulnerability produced by jsonp. Today, access has been fixed again, but I cannot find the chain that my brother submitted to wooyun.

Then I cried ~. (Note: The MIME media type for JSON text is application/json. The default encoding is UTF-8.

For JSONP with callback: application/javascript)

If you want to play, you can see an example of http://lorrylockie.github.io/2015/01/27/jsonp-safe/ here, such:

Access the link http://login.koudai.com/weidian/sendCodeToBuyerPhone? Param = % 20 {% 22 telephone % 22: % 2218601662827% 22, % 22country_code % 22: % 2286% 22} & callback = % 3 Cscript % 3 Ealert % 28/xxs/% 29; % 3C/script % 3E % 3 Cdiv % 20 style = % 22font-size: 100px; % 22% 3 EKOU % 20DAI % 20 TONG % 20DA % 20SHA % 20B % 3C/div % 3E & ver = 1031

Note: professional quality is required for security. The original po owner has already submitted it to wooyun and pocket communication. It is not the responsibility of white hats if they are not repaired. Of course, do not spoof it.

The response header is html, which causes xss attacks. You can view the source code of the webpage and click OK to view the browser output:

From this we can also verify what we said above about the jsonp application, such as normal requests to access the http://login.koudai.com/weidian/sendCodeToBuyerPhone? Param = % 20 {% 22 telephone % 22: % 2218601662827% 22, % 22country_code % 22: % 2286% 22} & callback = mycallback & ver = 1031

We can guess whether the entered telephone value is verified on the server, and use the returned status_code to indicate whether the value is valid. Then, we can perform the next step as a parameter of mycallback.

For example, send the Verification Code if it is correct. If we change the number to 18601662826 for access, the returned result is

Mycallback ({"status": {"status_code": 0, "status_reason": ""}) based on conjecture, I think this number actually exists.

For this type of reflection xss vulnerability caused by jsonp, the response header should be set correctly. Second, the callback parameter should be filtered or encoded to avoid direct execution of js.

Reference link:

Http://lorrylockie.github.io/2015/01/27/jsonp-safe/

Http://en.wikipedia.org/wiki/JSONP

Http://stackoverflow.com/questions/2067472/what-is-jsonp-all-about