What is a CSRF attack?

Cross-site Request Forgery (CSRF), a malicious website initiates a malicious Request to the URL of another page opened by the current user’s browser through a script. Due to the visibility of cookies in the same browser process, the user’s identity is stolen. Completes the actions specified in the malicious site script.

Although it sounds similar to XSS cross-site scripting, CSRF is very different from XSS in that XSS exploits trusted users within the site, while CSRF exploits trusted sites by masquerading requests from trusted users.

You can think of a CSRF attack this way: An attacker steals your identity and sends malicious requests to third-party websites on your behalf. CRSF can use your identity to email, text, transfer transactions, and even steal your account.

CSRF attack mechanism

The following figure shows the attack mechanism of CSRF.

  • First, user C browses and logs in to trusted site A.
  • After the login information is verified, site A will return the login cookie to the browser, and the cookie information will be saved in the browser for A certain period of time (depending on the server Settings).
  • Once this is done, the user accesses malicious site B without logging out of site A (clearing cookies from site A).
  • At this time, A page of malicious site B initiates A request to site A, and this request will bring the cookie of site A saved by the browser;
  • Site A determines that the request is sent by user C based on the cookie carried in the request.

Therefore, site A reports user C’s permission to process the request initiated by malicious site B, and the request may send emails, short messages, messages, transfers and payments as user C. In this way, malicious site B achieves the purpose of forging user C’s request to site A.

“The victim only needs to do the following two things for the attacker to complete the CSRF attack:

  • Log in to trusted site A and generate cookies locally;
  • Access malicious site B without logging out of site A (clearing cookies from site A).

In many cases, the so-called malicious site is likely to be a trusted and widely visited site with other vulnerabilities (such as XSS), so that ordinary users may be unknowingly victimized.

CSRF defense

Use POST as much as possible and limit GET

The GET interface is too easy to use for CSRF attacks, as the first example shows, simply by constructing an IMG tag, which is unfiltered data. You are advised to limit the use of the interface to POST. GET is invalid to reduce attack risks.

Of course, POST is not foolproof. An attacker can simply create a form, but it needs to be done on a third-party page, which increases the possibility of exposure.

Browser Cookie Policy

By default, Internet Explorer 6, 7, 8, and Safari block sending third-party local cookies. However, Firefox2, 3, Opera, Chrome, and Android do not block CSRF attacks, so using the browser Cookie policy to defend against CSRF attacks is not reliable, but can only reduce the risk.

PS: Cookies are divided into two types: Session cookies (which expire after the browser closes and are saved in memory) and third-party cookies (which expire after the Exprie time and are saved locally).

PS: In addition, if the web site returns an HTTP Header containing the P3P Header, it will allow the browser to send third-party cookies.

Add validation code

A verification code that forces the user to interact with the application before completing the final request. In general, captchas are good at deterring CSRF attacks. But for the sake of user experience, sites can’t add captcha codes to all operations. Therefore, captchas can only be used as an auxiliary means, not as the main solution.

Referer Check

The most common use of Referer Check on the Web is to prevent image theft. In the same way, the Referer Check can be used to Check whether the request is coming from a legitimate “source” (whether the Referer value is the specified page, or the domain of the site), and if neither is, it is most likely a CSRF attack.

However, because the server does not always have access to the Referer, it cannot be used as a primary means of CSRF defense. However, Referer Check is a feasible method to monitor the occurrence of CSRF attacks.

Anti CSRF Token

Now the industry defense against CSRF, the consistent approach is to use a Token (Anti CSRF Token).

  1. A user visits a form page.
  2. The server generates a Token and places it in the user’s Session or in the browser’s Cookie.
  3. Attach the Token parameter to the page form.
  4. After a user submits a request, the server verifies whether the Token in the form is the same as the Token in the user Session (or Cookies). If the Token in the form is the same, the request is valid. If the Token in the form is not invalid, the request is invalid.

The value of this Token must be random and unpredictable. Because of the Token, the attacker can no longer construct a request with a valid Token to carry out a CSRF attack. In addition, when using tokens, you should pay attention to the confidentiality of tokens. Try to change sensitive operations from GET to POST and submit them in form or AJAX to avoid Token disclosure.

Pay attention to

CSRF tokens are only used to defend against CSRF attacks. When the site also has XSS vulnerability, then this solution is also empty. Therefore, XSS problems should be solved using XSS defense solutions.

From: my.oschina.net/lienson/blo…