CSRF/XSRF – Cross Site Request Forgery

Cross-site request forgery: An attacker lures the victim to a third-party site where a cross-site request is sent to the targeted site. Using the victim in the attacked website has obtained the registration certificate, bypassing the background user authentication, to impersonate the user to perform a certain operation on the attacked website. A typical CSRF attack has the following flow:

  • Victims log on to the website and retain their login credentials (cookies).
  • The attacker lured the victim to visit b.com.
  • B.com sent a request to a.com: a.com/act=xx. Browsers carry cookies from A.com by default.
  • When a.com received the request, it verified it and confirmed that it was the victim’s credentials, mistaking it as a request sent by the victim himself.
  • A.com enforced act= XX on behalf of the victims.
  • When the attack is complete, the attacker impersonates the victim without the victim’s knowledge and allows a.com to perform its own defined operation.

1. Several common attack types

  • CSRF of GET type: CSRF of GET type is very simple, only requires an HTTP request, the general operation is as follows.
<img src="http://bank.example/withdraw? amount=10000&for=hacker" >
Copy the code

After the victim visits the page containing the IMG, the browser automatically sends an HTTP GET request, and Bank.Example receives a cross-domain request containing the victim’s login information.

  • POST CSRF: This type of CSRF is typically exploited using an auto-submitted form, as shown below.
<form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>
Copy the code

When you visit the page, the form is automatically submitted, simulating a POST operation.

  • Link-type CSRF: Link-type CSRF is uncommon and requires the user to click the link to trigger it, compared to the other two cases where the user opens the page and is caught. This type is usually in the forum published in the picture embedded malicious links, or in the form of advertising to induce users to be lured, attackers will usually be more exaggerated words to lure users to click
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">Big news!!<a/>
Copy the code

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

2. Features of CSRF

  • Attacks are generally launched on third party sites, not the site being attacked. The attacked site cannot prevent the attack from happening.
  • Attack using the victim’s login credentials in the attacked website, posing as the victim to submit operations; Instead of stealing data directly.
  • The attacker can not obtain the login credentials of the victim during the whole process, just “fake”.
  • Cross-site requests can be made in a variety of ways: image urls, hyperlinks, CORS, Form submissions, and more. Part of the request can be directly embedded in third-party forums, articles, difficult to track.

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

3. Protection policies

CSRF is usually launched from third-party websites. Attacked websites cannot prevent attacks, but can only enhance their own protection against CSRF to improve security. The above mentioned two characteristics of CSRF are described:

  • CSRF (usually) occurs in third party domain names.
  • CSRF attackers cannot obtain information such as cookies, but only use.

For these two points, special protection strategies can be formulated as follows:

  • Block access to unknown outfields
    • Homologous detection
  • Samesite Cookie
  • Submit by asking for additional information that is available only to the local domain
    • CSRF Token
  • Double Cookie authentication

3.1 Homology detection

The purpose of same-origin detection is to prevent unsafe outdomain access. Since most CSRFS come from third-party websites, outlands (or untrusted domain names) are directly prohibited from making requests. In HTTP, each asynchronous request carries two headers, which mark the domain name of the source:

  • Origin Header
  • Referer Header

Therefore, the server can determine the source domain of the request by resolving the domain names in the two headers. And because of browser compatibility, the Origin and Referer fields may not exist, a principle is that when the Origin exists, you can directly use the fields in the Origin to confirm the source domain name. In 2014, the W3C’s Web Application Security Working Group published a draft Referrer Policy that specifies in detail how browsers should send referers. As of now, most newer browsers support this draft, so developers finally have the flexibility to control the Referer strategy for their sites. There are three ways to set the Referrer Policy:

  • In the CSP setting
  • Add meta tags to the header of the page
  • Add referrerPolicy attribute for a tag and IMG tag

One problem is that attackers can hide referers in their requests. If the attacker filled out his request like this:

 <img src="http://bank.example/withdraw? amount=10000&for=hacker" referrerpolicy="no-referrer">
Copy the code

Then the attack initiated by this request will not carry the Referer. In addition, Referer is not or cannot be trusted in the following cases:

  1. In IE6 and IE7, when window.location.href= URL is used to jump the interface, the Referer will be lost.
  2. When Windows. Open is used in IE6 and IE7, the Referer will also be missing.
  3. When the HTTPS page jumps to the HTTP page, all the browser referers are lost.
  4. When you click on Flash to get to another site, Referer’s situation is messy and unreliable.

So when the Origin and Referer headers do not exist, it is recommended to block them directly, especially if you are not using a random CSRF Token (see below) as a second check.

3.2 Outdomain Access Exceptions

When a request is a page request (such as the homepage of a website) and the source is a link from a search engine (such as baidu search results), it can also be considered as a suspected CSRF attack. Therefore, you need to filter out the page request when judging. Usually, the Header meets the following conditions:

Accept: text/html
Method: GET
Copy the code

In turn, page requests are exposed to CSRF attacks. If your site does something to the current user in a GET request on the page, the defense will fail. Therefore, the same origin policy also requires developers to make changes without using GET requests, which can only perform simple queries!

3.3 CSRF Token

CSRF Token defends against attacks based on the following: attackers cannot directly steal user information (cookies, headers, website content, etc.), but only use the information in cookies. Therefore, all user requests can be made to carry a Token that a CSRF attacker cannot obtain. By verifying whether the request carries the correct Token, the server can distinguish the normal request from the attack request and defend against CSRF attacks. The CSRF Token defense policy consists of three steps, which are described one by one.

3.3.1 Output the CSRF Token to the Page

First, when a user opens a page, the server generates a Token for the user, which encrypts the data using an encryption algorithm. Tokens usually consist of random strings and timestamps. Obviously, the Token cannot be placed in the Cookie at the time of submission, otherwise it will be used by attackers. Therefore, for the sake of security, it is better to keep the Token in the server’s Session, then use JS to traverse the whole DOM tree every time the page loads, and add the Token for all a and form tags in the DOM. This solves most requests, but for HTML code that is generated dynamically after the page loads, this approach does not work and requires the programmer to manually add tokens at coding time.

So the Token is generated by the server and returned to the front end in a secure way (usually with the login information). The front-end stores the Token. Do not store the Token in a Cookie. Otherwise, the Token may be used by attackers. Tokens (Get/Post/Put/Delete) need to be added for each subsequent request from the front end.

Global add token can request the filter implementation, such as axios provides axios. Interceptors. Request. Use to all requests of filtering

3.3.2 Page submitted requests carry this Token

For GET requests, the Token is appended to the request address so that the URL becomes http://url? Csrftoken = tokenvalue. For POST requests, the form ends with:

<input type="Hidden" name="Csrftoken" value=Tokenvalue "/">
Copy the code

This adds the Token to the request as a parameter.

3.3.3 The server verifies the Token

When a user obtains a Token from the client and submits it to the server again, the server needs to determine the validity of the Token by decrypting the Token and comparing the encrypted string with the timestamp. If the encrypted string is consistent and the time has not expired, the Token is valid. This method is a bit safer than checking Referer or Origin before. Tokens can be generated and placed in the Session, and then taken out of the Session on each request and compared with the tokens in the request. The trickier part of this approach, however, is how to add tokens to the request as parameters.

You are advised to use the Request instance filter to add a custom token. Requests from the entire site cannot be intercepted globally. Otherwise, attack requests will be added with tokens, and the defense mechanism becomes invalid

Typically, developers only need to generate tokens once for the current session. After the initial generation of this Token, the value is stored in the session and used for each subsequent request until the session expires. When an end user makes a request, the server side must verify the existence and validity of the Token in the request against the Token found in the session. If the Token is not found in the request, or the value provided does not match the value in the session, the request should be aborted, the Token should be reset and the event logged as a potential CSRF attack in progress.

3.3.4 Verifying the Token in distributed mode

At present, large websites adopt distributed deployment. HTTP requests initiated by users usually go through load balancers such as Ngnix and then route to specific servers. As Session is stored in the memory of single server by default, Therefore, in a distributed environment, multiple HTTP requests sent by the same user may be sent to different servers successively. As a result, subsequent HTTP requests cannot obtain the Session data stored in the previous HTTP requests. As a result, the Session mechanism becomes invalid in the distributed environment. The solution: CSRF tokens need to be stored in a common storage space such as Redis in a distributed cluster. As Session storage is used, reading and verifying CSRF tokens will cause relatively large complexity and performance problems. Currently, many websites adopt Encrypted Token Pattern mode. The Token of this approach is a calculated result, not a randomly generated string. In this way, there is no need to read the stored Token during verification, but only need to calculate the Token again. Solve the problem of session sharing in distributed environment :(session sharing also affects Token sharing)

  1. The redis public storage service is used to store sessions and realize session sharing
  2. Encrypted Token Pattern is used to calculate the Token

3.3.5 Token Defense Summary

Token is a relatively effective CSRF defense method. As long as the page does not have XSS vulnerability to expose the Token, the CSRF attack on the interface will not succeed. However, the implementation of this method is complicated. It needs to write a Token to every page (pure static pages cannot be used in the front end). Every Form and Ajax request carries this Token, and the back end verifies every interface to ensure that the page Token and request Token are consistent.

4. Double cookies

4.1 Implementation Principle

Taking advantage of the fact that CSRF attacks cannot capture user cookies, we can require Ajax and form requests to carry a Cookie value that has no business significance and serves only for security verification. Double Cookie uses the following process:

  • When a user visits a web page, a Cookie is injected into the requested domain with a random string of content (for example, cSRFcookie =v8g9e4ksfhw).
  • When the front end sends a request to the back end, the Cookie is fetched and added to the PARAMETERS of the URL (following example POST www.a.com/comment?csr…
  • The back-end interface verifies whether the fields in the Cookie are consistent with those in the URL parameter, and rejects any inconsistency.

Of course, this method has not been applied on a large scale, and its security on large websites is still not as high as that of CSRF Token. The reasons are illustrated below. Since any cross-domain will cause the front end to be unable to get the fields in the Cookie (including between subdomains), the following happens:

  • If the user accesses the website www.a.com, the back-end API domain name is api.a.com. So in www.a.com, the front end can not get the Cookie of API.a.com, it can not complete double Cookie authentication.
  • The authentication Cookie must then be planted under a.com so that each subdomain can access it.
  • Any subdomain can modify the cookies under a.com.
  • A subdomain has been attacked by XSS (for example, upload.a.com). Although there is nothing worth stealing in this subdomain. But the attacker modified the cookies under a.com.
  • Attackers can directly use their own cookies to launch CSRF attacks against users caught in XSS to www.a.com.

4.2 Advantages of dual cookies

Advantages of using dual cookies to defend against CSRF:

  • No need to use Session, more widely applicable, easy to implement.
  • The Token is stored in the client and does not put pressure on the server.
  • Compared with Token, the implementation cost is lower, and the verification can be uniformly intercepted at the front and back ends without the need to add interfaces and pages one by one.

4.3 Disadvantages of double cookies

Disadvantages:

  • Additional fields are added to cookies.
  • If there are other vulnerabilities (such as XSS) where the attacker can inject cookies, this defense fails.
  • Isolation of subdomains is difficult.
  • In order to ensure the security of Cookie transmission, it is best to use this defense mode to ensure that the whole site HTTPS mode is used. If HTTPS is not used, this mode may also be risky.

5. Samesite Cookie attribute

In order to solve this problem at the source, Google drafted a draft to improve the HTTP protocol, that is, to add the Samesite attribute to the set-cookie response header, which is used to indicate that the Cookie is a “peer Cookie”, and the peer Cookie can only be used as a first-party Cookie. Cannot be a third-party Cookie, Samesite has two property values, Strict and Lax.

5.1 Samesite = Strict

This mode, called strict mode, indicates that the Cookie cannot be used as a third-party Cookie under any circumstances, without exception. For example, b.com sets the following Cookie:

Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax
Set-Cookie: baz=3
Copy the code

Cookie foo will not be included in the Cookie header for any request to b.com made under a.com, but bar will. For example, if the Cookie used by Taobao website to identify whether users log in or not is set to Samesite = Strict, then after users click on the link of Baidu search page or even Tmall page to enter Taobao, Taobao will not be logged in. Because Taobao’s servers do not accept the Cookie, any request to Taobao from other websites does not carry the Cookie.

5.2 Samesite = Lax

This is called loose mode and is a bit more restrictive than Strict: if the request is one of these (changes the current page or opens a new page) and is also a GET request, the Cookie can be used as a third-party Cookie. For example, b.com sets the following Cookie:

Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax
Set-Cookie: baz=3
Copy the code

When a user clicks a link from a.com to b.com, the Cookie foo will not be included in the Cookie request header, but bar and Baz will. In other words, the user will not be affected by the link between different websites. However, bar will not send the request if it is an asynchronous request to B.com from a.com, or if the page jump is triggered by a POST submission of the form.

6. Prevent attacks

What is said in front is how to protect the websites that are attacked. Instead of preventing attacks, CSRF attacks can come from:

  • The attacker’s own website.
  • Have file upload bug site.
  • Third party forums and other user content.
  • The attacked website’s own comment function.

For websites from hackers themselves, there is no protection. But in other cases, how do you prevent your website from being used as a source of attack?

  • Strictly manage all upload interfaces to prevent any unexpected uploads (such as HTML).
  • Add Header x-Content-type-options: Nosniffing Prevents HTML resources (such as images) uploaded by hackers from being parsed as Web pages.
  • For pictures uploaded by users, it can be saved or verified. Do not directly use the image link that the user fills in.
  • Current users need to be notified of the risks when opening links filled in by other users (this is one of the reasons many forums don’t allow outland links to be posted directly in their content, not just for retention but also for security reasons).

conclusion

  • CSRF automatic defense policy: Origin detection (Origin and Referer verification).
  • CSRF active defense measures: Token authentication or double Cookie authentication and Samesite cookies.
  • To keep the page idempotent, the back-end interface does not edit (add, delete, change) in GET requests.