Cross-site Request Forgery (CSRF) : An attacker induces the victim to access a third-party website, and in a third website, sends a cross-site request to the target website. Using the victim in the attacked website has obtained the registration credentials, bypassing the background user authentication, to achieve the purpose of impersonating the user to perform some operations on the attacked website.
Typical CSRF attack flow:
- Victims log on to the website and retain their login credentials (cookies).
- The attacker lures victims to visit b.com.
- B.com sends a request to a.com: a.com/act=xxx; Browsers carry cookies from A.com
- When a.com received the request, it verified the request and confirmed the victim’s credentials, mistakenly believing that the victim sent the request himself.
- A.com enforces act= XXX 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.
Common attack types
GET the type
<img src="http://bank.example/withdraw? amount=10000&for=hacker" />
Let the browser automatically make an HTTP request through the label of the image.
POST type
This is usually an automatically submitted form
<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
Link type
Link-type CSRFS are uncommon and require the user to click a link to trigger them, compared to the other two cases where the user opens the page and is caught. This type usually involves embedding malicious links in the pictures published in the forum, or inducing users to be lured in the form of advertisements. Attackers usually trick users into clicking with exaggerated words, such as:
<a
href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker"
taget="_blank"
>Big news!!<a
/></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.
Same-origin policy Indicates the Same origin policy
Same-origin policy
CSRF is restricted by the same origin policy, but img, script, and form can still be used to achieve cross-domain effects, because these HTML tags have cross-domain capabilities.
The characteristics 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 comment sections for Posting pictures and links, the attack can be carried out directly in the local domain, and this attack is more dangerous.
Protection strategy
Based on two features of CSRF:
- CSRF (usually) occurs in third party domain names
- CSRF attackers cannot obtain information such as cookies, but only use.
Protection policy:
- Block access to unknown outfields
- Homology detection??
- Samesite Cookie
- Submit by asking for additional information that is available only to the local domain
- CSRF Token
- Double Cookie authentication
Block access to unknown outfields
Homologous detection
-
Origin Header
The Origin Header is used to check whether Internet Explorer 11 has the same Origin policy. The Origin Header is not included in the 302 redirection request.
-
Referer Header
The Referer Header records the source address of the HTTP request.
Referer Policy
Setting the Referrer Policy
- In the CSP setting
- Add meta tags to the header of the page
- A tag adds the referrerPolicy attribute
If the Origin Header or Referrer Header cannot be used to confirm the source of the request, it is recommended to block it directly.
How do I block outfield requests
In the general website, there is no user input website, you can use the above method to achieve CSRF control, but for the search engine request, will also become CSRF attack; The Origin Header and Referrer will also be invalid if the user attacks the UGC site from within.
CSRF Token (handle user information fraud)
Principle:
-
Outputs the CSRF Token to the page
After login, the Token is passed to the front end and added to the DOM tree when the form is submitted, not to dynamically generated HTML code.
-
The request submitted by the page carries this Token
-
The server verifies that the Token is correct
When verifying the tokens, the server takes out the tokens in the client Session and sends them to the server. If the server is distributed, it needs to cache the user’s tokens through Redis to ensure the validity of the tokens. Further, a Token can be calculated using UserId, timestamp, and so on.
Double Cookie authentication
Double Cookie uses the following process:
- When a user visits a web page, a Cookie is injected into the requested domain name with a random string of content (e.g
csrfcookie=v8g9e4ksfhw
). - When the front end makes a request to the back end, the Cookie is fetched and added to the parameters of the URL (following example)
POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw
). - The back-end interface verifies whether the fields in the Cookie are consistent with those in the URL parameter, and rejects any inconsistency.
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.
- 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.
Samesite Cookie attribute
The Samesite property of the Cookie is used to indicate whether the Cookie is for the Samesite and cannot be used by third parties. It has two values Lax and Strict.
Samesite=Strict
Under no circumstances can this cookie be used by third parties.
Samesite=Lax
If the request is one of these (changing the current page or opening a new page) and is also a Get✔️ request, the Cookie can be used as a third-party Cookie.
From A to B, if the page is opened and A Get✔️ request is made, the Cookie will be carried, but if another step is made on page B, the Cookie will not be carried.
The disadvantage of Samesite
- In Lax, the user remains logged in if entering a subdomain, which is fine for the user experience, but Strict can’t keep the user logged in at the subdomain.
- Currently, the SameSite attribute is not very well supported, with the exception of Chrome and FireFox.
- Key defect: does not support subdomain, if the cookie set in the a.com, top.a.com is not available, need to log in again.
Prevent the site from being exploited
How do I prevent attacks from happening on my own website
- Strictly manage all upload interfaces to prevent any unexpected uploads (such as HTML)
- Add the Header
X-Content-Type-Options: nosniff
Prevents hackers from uploading HTML content to resources that are parsed into 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.
- The current user should be informed of the risks when opening links filled in by other users.
PS:
Front-end Security Series 2: How do I Prevent CSRF Attacks?