Many factories like to ask questions about web security during the interview, such as the next one, what is CSRF and what are the preventive measures? This article will take you through CSRF.
What is CSRF?
Cross Site Request Forgery is a network attack mode.
We see it through an example:
Xiao Ming logged in a bank website www.bank.com, and the bank server sent a cookie,
Set-Cookie:id=a3fWa;
Later, Xiao Ming visited a malicious website www.hacker.com, which had a form
<form action='www.bank.com/transfer' method='POST'>
...
</form>
Copy the code
Xiao Ming inadvertently triggered this form, the bank server will receive the request with the correct cookie, and then the bank server will perform its own defined operation transfer, at this time it is possible to transfer the money from Xiao Ming’s account.
CSRF characteristics
- Attacks usually occur on third-party sites, not the targeted sites;
- The attack uses users’ login credentials (cookies) in the attacked website to pretend to be the victim to submit operations, rather than directly stealing data;
- In the whole process, the attacker cannot obtain the login credentials, but uses them falsely.
- Cross-site requests can be made in a variety of ways: SRC for img images, A tag, form submission, and so on;
Would you say horrible? Sure, how do you prevent CSRF attacks? You might say, well, the user doesn’t have to click through to a malicious site. That’s fine, but you can’t guarantee that everyone won’t click on a malicious site, so we still have to do automatic defense, even if people visit a malicious site, we have to make sure that our site won’t be attacked.
Defensive measures
As we know, CSRF usually occurs on third-party websites, and attackers only use login credentials instead of obtaining login credentials data, so we formulate the following prevention strategies:
-
Block access to unknown external domain names
- Homologous detection
- Samesite Cookie
-
When submitting the Form, add the authentication information that is available only for the local field
- CSRF token
1. Homology detection
The Cookie’s same-origin policy differs from the browser’s same-origin policy:
* Browser same-origin policy: If the protocol, domain name, and port are the same, the browser is same-origin. * Cookie same-origin policy: The same domain name means same-origin.Copy the code
In HTTP, each asynchronous request carries two headers that mark the domain name from which it came:
* Origin Header
* Referer Header
Copy the code
These two headers are automatically carried in most cases when the browser initiates a request and cannot be modified by the front end. The server can determine the domain name of the source based on these two headers after receiving the request.
Special case: If neither Origin nor Referer exists, it is recommended to block it directly, especially if you are not using a random CSRF Token (see below) as a second check.
In addition, CSRFS are mostly from third-party domain names, but local domain initiation cannot be ruled out. If an attacker has permission to post comments (including links and images) in the local domain, it can directly launch attacks in the local domain. In this case, the same-origin policy cannot protect against such attacks.
** In summary: ** Homologous authentication is a relatively simple defense method that can protect against the vast majority of CSRF attacks. But it’s not foolproof. For sites with high security requirements or a lot of user input, we need to put extra safeguards on key interfaces.
2. Samesite Cookie attribute
Starting with Chrome 51, a SameSite property is added to the browser’s Cookie to protect against CSRF attacks.
The Samesite property of cookies, which limits third-party cookies to reduce security risks, has three values:
Set-Cookie: SameSite = Strict;
Set-Cookie: SameSite = Lax;
Set-Cookie: SameSite = None;
Copy the code
Strict: the strictest, completely prohibit third-party cookies, cross-site, do not send cookies under any circumstances; Lax: slightly less restrictive, no third-party cookies are sent in most cases, except for a link, preload request, and GET forms; None: The SameSite property is turned off, but the Secure property must be set as follows:
Set-cookie: SameSite = None // invalid set-cookie: SameSite = None; Secure / / is validCopy the code
Setting Strict or Lax basically prevents CSRF attacks, as long as the browser supports the SameSite property.
3.CSRF token
The CSRF attack can succeed because the server considers the Cookie carried by the attacker as a normal user request. Then we can require all user requests to carry a token that cannot be hijacked by the attacker. Each request carries this token, and the server can prevent CSRF by verifying whether the request is a correct token Attack.
The CSRF token defense policy consists of three steps:
-
First, when a user opens a page, the server needs to generate a token for the user, which encrypts the data using an encryption algorithm. Generally, the token consists of a random string and a timestamp. Obviously, the token can no longer be placed in a Cookie during submission. Otherwise it will be used by attackers.
-
For GET requests, attach the token to the request address, for example: http://url? Token =tokenValue For POST requests, the token is appended to the Form
< input type = "hidden" name = "tokenvalue token" value = "" / >Copy the code
- The server verifies the token. After receiving the token from the client, the server decrypts the token and checks whether random strings are consistent and valid. If the strings are consistent and within the validity period, the token is correct.
conclusion
Briefly summarize the above CSRF attack defense strategy:
- Automatic Protection policy: Homologous Detection (
Origin
andReferer
Validation); - Active protection strategy:
token
Verification and coordinationSameSite
Settings; - Protect the idempotent nature of the page and don’t do user actions in GET requests
In order to better defend against CSRF, the best practice is to consider the advantages and disadvantages of the defense measures summarized above and make appropriate choices based on the current situation of the Web application to better prevent THE occurrence of CSRF.