Shulou(Shulou.com)06/01 Report--

This article is to share with you the content of a sample analysis of CSRF attacks. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

CSRF attack

What is a CSRF attack?

CSRF full name Cross-site request forgery, Chinese for cross-site request forgery, the attacker induced the victim to enter the third-party website, in the third-party website, send cross-site request to the attacked website. Use the registration credentials that the victim has obtained in the attacked website to bypass the background user authentication to achieve the purpose of pretending to be a user to perform an operation on the attacked website. CSRF attack is that hackers take advantage of the login status of users and do some bad things through third-party sites.

Several common types of attack

CSRF of type 1.GET

CSRF of type GET is very simple and usually requires only one HTTP request:

After the victim visits the page containing the img, the browser automatically sends a HTTP request to http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker. Bank.example will receive a cross-domain request containing the victim's login information.

CSRF of type 2.POST

This type of CSRF is usually leveraged with an automatically submitted form, such as:

Document.forms [0] .submit ()

After visiting the page, the form is automatically submitted, which is equivalent to simulating the user to complete a POST operation.

3. CSRF of link type

Link-type CSRF is not common, and it requires users to click on the link to trigger it, compared with the other two situations in which users get hit when they open the page. This type usually embeds malicious links in pictures posted in forums, or lures users into clicks in the form of advertisements, and attackers usually trick users into clicking with exaggerated words, such as:

Big news!

Since the user previously logged in to the trusted website An and saved the login status, as long as the user actively visited the above PHP page, the attack was successful.

Characteristics of CSRF

Attacks are generally launched on third-party websites, not on the attacked sites. The attacked website cannot prevent the attack from happening.

The attack uses the victim's login credentials on the attacked website to impersonate the victim to submit the operation, rather than directly stealing data.

Throughout the process, the attacker can not get the victim's login credentials, just "fake".

Cross-site requests can be made in a variety of ways: picture URL, hyperlink, CORS, Form submission, and so on. Some of the request methods can be directly embedded in third-party forums and articles, which is difficult to track.

CSRF is usually cross-domain because outdomains are usually more easily controlled by attackers. However, if there are easily exploited functions in this domain, such as forums and comment areas that can post pictures and links, attacks can be carried out directly in this domain, and such attacks are more dangerous.

Protection strategy

Hackers can only use the victim's cookie to swindle the trust of the server, but hackers can not get * * "cookie" * *, nor can they see the content of * * "cookie". In addition, the results returned by the server cannot be parsed by the hacker due to the limitation of the browser's "same origin policy".

This tells us that the objects we want to protect are services that can directly produce data changes, while services that read data do not need to be protected by CSRF. The key to protection is to "put in the request information that the hacker cannot forge."

Homology detection

Since most of the CSRF comes from third-party websites, we directly prohibit external domains (or untrusted domain names) from making requests to us.

So the question is, how do we tell if the request comes from Outland?

In the HTTP protocol, each asynchronous request carries two Header to mark the source domain name:

Origin Header

Referer Header

These two Header are brought automatically in most cases when the browser initiates a request, and the content cannot be customized by the front end. The server can determine the source domain of the request by parsing the domain names in the two Header.

Use Origin Header to determine the source domain name

In some requests related to CSRF, the Origin field is carried in the requested Header. The field contains the requested domain name (excluding path and query).

If Origin exists, you can directly use the fields in Origin to confirm the source domain name.

However, Origin does not exist in the following two situations:

IE11 homology policy: IE11 will not add Origin headers to cross-site CORS requests, and Referer headers will still be unique identifiers. The most fundamental reason is that the definition of homology in IE 11 is different from that of other browsers. There are two main differences. Please refer to MDN Same-origin_policy#IE_Exceptions.

Redirect: the Origin is not included in the redirected request after the 302 redirection, because the Origin may be considered sensitive information from other sources. In the case of 302 redirection, it is directed to the URL on the new server, so the browser does not want to leak the Origin to the new server.

Use Referer Header to determine the source domain name

According to the HTTP protocol, there is a field in the HTTP header called Referer, which records the source address of the HTTP request. For Ajax requests, images, script and other resource requests, Referer is the address of the page that initiated the request. For page jumps, Referer is the previous page address that opened the page history. So we can use the Origin section of the link in Referer to know the source domain name of the request.

This method is not foolproof, the value of Referer is provided by the browser, although there are clear requirements on the HTTP protocol, but each browser for the specific implementation of Referer may be different, there is no guarantee that the browser itself does not have security vulnerabilities. Using the method of validating Referer values is to rely on third parties (that is, browsers) for security, which is not very secure in theory. In some cases, attackers can hide or even modify their requested Referer.

In 2014, the W3C Web Application Security working Group released a draft of Referrer Policy, which specifies in detail how browsers should send Referer. Up to now, most of the new browsers have supported this draft, and we finally have the flexibility to control the Referer strategy of our website. The new version of Referrer Policy specifies five Referer strategies: No Referrer, No Referrer When Downgrade, Origin Only, Origin When Cross-origin, and Unsafe URL. The three pre-existing strategies, never, default and always, have been renamed in the new standard. Their corresponding relationship is as follows:

Policy name attribute value (new) attribute value (old) No Referrerno-ReferrerneverNo Referrer When Downgradeno-Referrer-when-downgradedefaultOrigin Only (same or strict) originoriginOrigin When Cross Origin (strict) origin-when-crossorigin-Unsafe URLunsafe-urlalways

According to the above table, you need to set the policy of Referrer Policy to same-origin, send Referer for links and references of the same origin, and the referer value is Host without Path; cross-domain access without Referer. For example, aaa.com refers to the resources of bbb.com and does not send Referer.

There are three ways to set up Referrer Policy:

Set up in CSP

Add meta tags to the header of the page

A tag adds a referrerpolicy attribute

There's a lot of this, but we know one problem: attackers can hide Referer in their own requests. If the attacker fills in his own request as follows:

Then the attack launched by this request will not carry Referer.

In addition, Referer is not or cannot be trusted under the following circumstances:

If you use _ window.location.href=url to jump to the interface under 1.IE6 and 7, you will lose Referer.

If you use window.open under 2.IE6 and 7, Referer will also be missing.

The 3.HTTPS page jumps to the HTTP page and all browsers Referer are lost.

4. When you click on Flash to get to another website, Referer's situation is messy and unreliable.

Unable to confirm the source domain name

What should I do when the Origin and referer header files do not exist? If neither Origin nor Referer exists, it is recommended to block them directly, especially if you are not using random CSRF Token (see below) as a second check.

How to block external domain requests

Through the verification of Header, we can know the source domain name of the request, which may be the local domain of the website, or a sub-domain name, or an authorized third-party domain name, or an unknown domain name that cannot be trusted.

We already know whether the requested domain name comes from an untrusted domain name. Can we prevent CSRF attacks by blocking these requests directly?

Wait a minute! When a request is a page request (such as the home page of a website) and the source is a link from a search engine (such as Baidu's search results), it will also be regarded as a suspected CSRF attack. Therefore, when judging, you need to filter out the page request. Usually, Header meets the following conditions:

Accept: text/htmlMethod: GET

But accordingly, the page request is exposed to the scope of the CSRF attack. If your site does something to the current user in the GET request of the page, the prevention will be ineffective.

For example, the following page request:

GET https://example.com/addComment?comment=XXX&dest=orderId

Note: strictly speaking, there is not necessarily a risk of CSRF attacks, but there are still many websites that often hang the main document GET request with parameters to achieve product functionality, but there is a security risk for themselves to do so.

In addition, as mentioned earlier, CSRF comes from a third-party domain name in most cases, but it does not rule out local domain origination. If an attacker has permission to post comments (including links, pictures, etc., collectively referred to as UGC) in this domain, he can launch attacks directly in this domain, in which case the same origin policy cannot achieve the protective effect.

To sum up: homology verification is a relatively simple defense method, which can prevent the vast majority of CSRF attacks. But this is not foolproof, for sites with higher security requirements or more user input, we have to take additional protection measures for key interfaces.

CSRF Token

Another feature of CSRF mentioned earlier is that attackers cannot directly steal the user's information (Cookie,Header, website content, etc.), just falsely using the information in Cookie.

The CSRF attack is successful because the server mistook the request sent by the attacker for the user's own request. Then we can require all user requests to carry a Token that CSRF attackers cannot get. By verifying whether the request carries the correct Token, the server distinguishes the normal request from the attacking request, and can also prevent CSRF attacks.

Make use of the SameSite attribute of Cookie

SameSite can be set to three values, Strict, Lax, and None.

In Strict mode, browsers completely prohibit third-party requests from carrying Cookie. For example, requesting sanyuan.com websites can only carry Cookie in the sanyuan.com domain name, but not in other websites.

In Lax mode, it's a little more relaxed, but you can only carry Cookie when the get method submits the form or the a tag sends a get request, and nothing else.

In None mode, Cookie will be sent in all contexts, that is, cross-domain transmission is allowed.

Thank you for reading! This is the end of this article on "sample Analysis of CSRF attacks". 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, you can 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.