Shulou(Shulou.com)05/31 Report--

This article will explain in detail the example analysis of read-based CSRF vulnerabilities. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

A case of read CSRFJSON hijacking vulnerability

Here's a request:

The result of this request returns a mobile phone number (the account I tested here is not bound to a mobile phone). What should we do if we want to obtain this mobile phone number in the way of CSRF interactive attack?

Let's see if this request has a callback, and is the result similar to a function in Javascript?

The original Javascript function is defined as follows:

Function funName () {}

Here is the lack of function definition keywords function and curly braces of the function body, only the function name and function parameters, smart people have thought of, this is not equivalent to the custom function is referenced, and the middle section of the parameter transfer is equivalent to an array, so we can first use JS to customize this function, and then reference this request, you can naturally get the data.

At this point, we can build PoC:

Function jsonp2 (data) {alert (JSON.stringify (data));}

Use a normal account (bound to a mobile phone number) to test:

Case summary

In fact, through this example, we can know that HTML tags can be read across domains under certain circumstances.

There are many fixes for this vulnerability:

1. Disrupt the main content of the response

Restrictions on 2.Referer, etc.

. Wait

Flash cross-domain hijacking

Flash cross-domain is a classic. When collating web directory assets, you will sometimes find such a file crossdomain.xml. If the file content is as follows, then there is a Flash cross-domain problem. The following means that all domains are supported:

Why is that? The specific process is as follows:

Gh0st.cn has a SWF file, which is the response body of the userinfo of vulkey.cn. SWF will first see if there is a crossdomain.xml file in the server directory of vulkey.cn. If there is no crossdomain.xml file, the access will not be successful. If there is crossdomain.xml, it will see whether the content of the crossdomain.xml file is set to allow gh0st.cn domain access. If the setting allows, then the SWF file of gh0st.cn can successfully obtain the content. So to enable Flash to transfer data across domains, the key is the crossdomain.xml file.

When you find that the content of the crossdomain.xml file is what I have shown above, then there is Flash cross-domain hijacking.

Loophole case

A file like this was found while testing a vendor:

There are two things I need to do here:

1. Find an interface that can get sensitive information

two。 Build PoC

Here the sensitive information interface takes personal center as an example, and PoC uses https://github.com/nccgroup/CrossSiteContentHijacking/raw/master/ContentHijacking/objects/ContentHijacking.swf.

Case summary

A very simple thing, but very useful, its use is the same as CSRF, only need to modify the PoC.

The fix is also simple and can be adjusted for the domain.

A case of CORS Cross-domain Resource Reading vulnerability

For example, in the above figure, I added the request header Origin: http://gh0st.cn to the request, and the response header Access-Control-Allow-Origin: http://gh0st.cn appears in the corresponding response package is actually access control permission. Here, the request of http://gh0st.cn is allowed, so http://gh0st.cn can read the content of this URL across domains. Here, I introduce Origin:

Origin is very similar to Referrer, except that the current request parameters are deleted, leaving only a triple (protocol host port). Standard browsers will carry Origin in every request, at least in cross-domain operations (such as ajax operations).

In fact, if you want to test whether cross-domain reading can be done, you can refer to my above method. Of course, you can directly use the wildcard character () to replace my domain name, because this represents an arbitrary domain. If a response header such as `domain: `appears in the corresponding response package, congratulations. There is a problem of arbitrary cross-domain resource reading.

How to use it? Here I use the open source project on github: there are specific instructions in https://github.com/nccgroup/CrossSiteContentHijacking Readme.md, so I won't explain them all here, so the problem has been identified and further verification is needed.

Here I found an interface where the main content of the response is to obtain the user's real name, ID card, mobile phone number and so on:

/ daren/author/query (note that this request is a POST request when fetching, but there is no request body. After testing, the request body is any content.)

Response message body content:

Here I built the CrossSiteContentHijacking project in the local (127.0.0.1) http://127.0.0.1/CrossSiteContentHijacking/ContentHijackingLoader.html.

Configure the parameters according to the operation described by the project, and then click the Retrieve Contents button:

The tests are as follows, and the test results can be read across domains:

Case summary

In fact, this problem is that the verification of Origin is not well controlled, so we can strengthen it.

This is the end of the article on "sample analysis of readable CSRF vulnerabilities". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.