1. What is CSRF
Cross-site Request Forgery (CSRF) : An attacker induces the victim to access a third-party website and sends cross-site request to the attacked website. To perform an operation using registration credentials that the victim has obtained from the targeted site.
2. CSRF classification
1. CSRF of GET type
It’s perfect for avoiding cross-domain problems
<! DOCTYPE html><html><head><meta charset="utf-8" /><title>csrf_1</title></head><body><img src='http://localhost.meetsocial.cn:8888/update?amount=1111'></body></html>Copy the code2. Cross-domain problems of the POST type
Iframe is even more subtle.
<html><head><meta charset="utf-8" /><title>csrf_2</title></head><body><iframe src='csrf_iframe.html'></iframe></body></html>
Copy the codeIframe page – csrf_iframe.html
<html><head><meta charset="utf-8" /><title>csrf_2</title></head><body><form method="POST" action="http://localhost.meetsocial.cn:8888/update"><input type="hidden" name="amount" value="2222"/></form><script>document.forms[0].submit(); </script></body></html>Copy the code3. CSRF of the link type
<html><head><meta charset="utf-8" /><title>csrf_3</title></head><body><a Href = "http://localhost.meetsocial.cn:8888/update?amount=1234" target = "_blank" > bombshell < / a > < / body > < / HTML >Copy the code3. The characteristics of CSRF
1. Attacks are generally launched on third party websites, not the site being attacked.
2. The attack takes advantage of the victim’s login credentials on the attacked website (so sometimes private browser access is safer), and impersonates the victim to submit operations
3. During the whole process, the attacker could not obtain the login credentials of the victim, but just used them falsely.
CSRF attacks have the following flow:
1. The victim logs in to the a.com and retains the login credentials (cookies).
2. The attacker lured the victim to visit b.com.
3.b.com sent a request to a.com: a.com/act=xx. Browsers carry cookies from A.com by default.
4.A.com will verify the request after receiving it and confirm that it is the victim’s credentials, mistakenly thinking that the request is sent by the victim himself.
5.a.com enforced act= XX on behalf of the victim.
6 attack completed, the attacker in the victim’s knowledge, posing as the victim, let the a.com to perform its own definition of the operation.
4. Protection policies
1. Homology detection
Most CSRFS come from third-party websites and directly prohibit outlands. Judge by the Referer Header.
This method is not foolproof, the Referer value is provided by the browser, although HTTP protocol has clear requirements, but each browser for the specific implementation of the Referer may be different, there is no guarantee that the browser itself does not have security vulnerabilities. The method of verifying the Referer value relies on the security of a third party (i.e. the browser), which in theory is not very secure. In some cases, attackers can hide or even modify the Referer of their own requests.
Homologous authentication is a relatively simple defense method and can prevent most 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. CSRF Token
The attacker cannot directly steal the user’s information (cookies, headers, website content, etc.), but only uses the information in cookies.
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:
1. Output the CSRF Token to the 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
2. The request submitted by the page carries 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:
3. The server verifies the Token
Tokens can be generated and placed in a Session, and then taken out of the Session on each request and compared with the tokens in the request.
Conclusion:
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.
Captchas and passwords can also act as CSRF tokens, and are more secure, though sometimes cumbersome. That’s why many banks and other websites require users who are already logged in to re-enter their passwords when transferring money.
2. Double Cookie authentication
Storing CSRF tokens in a session is cumbersome, and another defense is to use double-commit cookies.
Steps:
1. When the user accesses the website page, the server injects a Cookie (for example, csrFCookie =v8g9e4ksfhw) into the requested domain name.
2. When the front-end and back-end initiate a request, take out the Cookie, And add it to the parameters of the URL (following the example POST) [https://www.a.com/comment?csrfcookie=v8g9e4ksfhw] (https://www.a.com/comment?csrfcookie=v8g9e4ksfhw)).
3. The back-end interface verifies whether the fields in the Cookie are consistent with those in the URL parameter. If they are inconsistent, the interface rejects the Cookie.
Conclusion:
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.
Disadvantages:
- Additional fields are added to cookies.
- If there are other vulnerabilities (such as XSS) where the attacker can inject cookies, this defense fails.
- 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.
3.Samesite Cookie
It has three values:
1. Strict
Third party cookies are completely disabled and will not be sent across sites under any circumstances.
However, it is still possible to send cross-subdomain cookies on this page. Open the console of this page and output the following code:
fetch('http://david.meetsocial.cn:8888/update', {body: JSON.stringify({amount: 2}),credentials: 'include',method: 'POST'});
Copy the codeServer Settings:
if (req.headers.origin) {res.setHeader('Access-Control-Allow-Credentials', 'true'); res.setHeader('Access-Control-Allow-Origin', req.headers.origin); }Copy the code2. Lax
A GET request to navigate to a target url consists of only three cases: links, preloaded requests, and GET forms. See the table below.
Request type
The sample
normal
Lax
link
<a href="..." ></a>
Send a Cookie
Send a Cookie
preload
<link rel="prerender" href="..." />
Send a Cookie
Send a Cookie
GET the form
<form method="GET" action="..." >
Send a Cookie
Send a Cookie
POST form
<form method="POST" action="..." >
Send a Cookie
Don’t send
iframe
<iframe src="..." ></iframe>
Send a Cookie
Don’t send
AJAX
$.get("..." )
Send a Cookie
Don’t send
Image
<img src="..." >
Send a Cookie
Don’t send
3. None
Chrome plans to make Lax the default. At this point, the site can choose to explicitly turn off the SameSite property and set it to None.
However, the Secure attribute must be set at the same time (cookies can only be sent through HTTPS). Otherwise, cookies are invalid.
The Settings under Chrome’s plan for the future will not work, but are still available.
[document.cookie=](http://conf.meetsocial.cn:6688/pages/document.cookie=)``'aaa=111; SameSite=None; '
And Chrome has a warning:
A cookie associated with a resource at test-sso.meetsocial.cn/ was set with `SameSite=None` but without `Secure`. A future release of Chrome will only deliver cookies marked `SameSite=None` if they are also marked `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at www.chromestatus.com/feature/563… .
The following Settings are valid:
[document.cookie=](http://conf.meetsocial.cn:6688/pages/document.cookie=)``'bbb=2222; SameSite=None; Secure'
Conclusion:
1. Set Lax and enable POST on all interfaces to defend against CSRF attacks.
2. Although Strict also supports cookies, it also prevents search engines from clicking on login cookies carried by links, so it’s not recommended.
3. The SameSite Settings are Strict, Lax, and None, which support the Strict, Lax, and None Settings for this page to send a request with ** cookies across subdomains.
Conclusion 5.
CSRF attacks can come from:
1. The attacker’s own website.
2. Websites with file upload vulnerabilities.
3. Third-party forums and other user content.
4. The attacked website’s own comment function, etc. (Submit form comments directly, so does the captcha)
How to prevent your website from being used as a source of attack:
1. Strictly manage all upload interfaces to prevent any unexpected uploaded content (such as HTML).
2. Add Header x-Content-type-options: Nosniffing Prevents HTML resources (such as images) uploaded by hackers from being parsed as Web pages. – to be verified
3. Upload or verify pictures uploaded by users. Do not directly use the image link that the user fills in.
4. Current users should be notified of the risks when opening links filled in by other users (this is one of the reasons many forums do not allow outland links to be posted directly in their content, not only for retention but also for security reasons).
A brief summary of the above protection strategies:
1. CSRF automatic defense policy: Origin detection (Origin verification and Referer verification).
2. CSRF active defense measures: Token authentication or double Cookie authentication and Samesite cookies.
3. Ensure idempotency of the page and do not perform user operations on the GET page.