As a companion piece, it is recommended to start with a real-world example of an XSS attack.
The relationship between the two attacks and the Samesite and HttpOnly properties of cookies will be summarized later.
What is a CSRF attack?
Surfing the net these years, we often hear a sentence: “Don’t click that link, be careful there is a virus!” . So the question is, how can I just click on a link and get a virus? How did this “virus” steal my account?
The full name of CSRF is Cross-site request Forgery, so it is also called “cross-site request forgery”. It refers to a cross-site request initiated by a hacker who lures a user to open a hacker’s website and uses the user’s login status in the hacker’s website. Simply put, a CSRF attack is when a hacker takes advantage of a user’s login status and uses a third party’s site to do something bad.
An ancient example:
Back in 2007, David used his browser to open an email in Gmail and clicked on a link in the email. A few days later, David found out that his domain name had been stolen. Although David eventually got the domain name back through guanxi (a relationship he met through Internet surfing). Stolen domain names, because of the link accidentally clicked.
So how did the hacker steal David’s domain name?
- First, David initiates a login to Gmail using the browser, and then the Gmail server returns some login status cookies, Session and so on to the browser.
- The hacker then enticed David to open his link, and on the XXx.com page, the hacker wrote a request for a mail filter to access the Gmail interface, setting up the new mail filtering feature, because in the same browser, The request can get some authentication information such as login status cookies returned by the server to Gmail, and all the emails are smoothly set to be forwarded to the hacker’s mailbox.
- The hacker retrieved the password of the domain name account through the email, and then transferred the domain name to the hacker’s account.
That is the truth of the mystery of David’s domain name theft, the first two steps of which are CSRF attacks.
After getting his domain name back, David also shared the entire attack on his site, which you can refer to if you are interested (rest assured that this link will not save you from CSRF attacks).
How do I conduct a CSRF attack?
There are three ways to launch a CSRF attack.
Suppose you now have a bank transfer interface
# Support POST and Get
# interface
https://www.bank.com/sendmoney
# parameters
## Target users
user
## Target amount
number
Copy the code1. Automatically initiates a GET request
The easiest thing for a hacker to do is send a GET request without the user noticing.
<html>
<body>
<h1>Hacker's Site: CSRF attack demo</h1>
<img src="https://www.bank.com/sendmoney?user=hacker&number=100">
</body>
</html>
Copy the codeWhen the user visits the link, the transfer request interface is hidden inside the IMG tag, which the browser assumes is an image resource. Send a request, the server thinks the request is a transfer request, and the $100 from the user’s account is transferred to the hacker’s account.
2. Automatically sends a POST request
For interfaces that use POST, a bogus POST request is made on the site and automatically submitted when the user clicks on the link.
<html>
<body>
<h1>Hacker's Site: CSRF attack demo</h1>
<form id='hacker-form' action="https://time.geekbang.org/sendcoin" method=POST>
<input type="hidden" name="user" value="hacker" />
<input type="hidden" name="number" value="100" />
</form>
<script> document.getElementById('hacker-form').submit(); </script>
</body>
</html>
Copy the code3. Decoy links
This is often used in mailboxes or forums to entice users to click on links.
<div>
<img width=150 src=http://images.xuejuzi.cn/1612/1_161230185104_1.jpg> </img> </div> <div>
<a href="https://www.bank.com/sendmoney?user=hacker&number=100" taget="_blank">
Click to download photos of beautiful women
</a>
</div>
Copy the code
I just want to know if you’re feeling it? (the head)
On the hacker’s page, a picture of a beautiful woman was posted with a download address, which was actually a link the hacker used to transfer money. Once the user clicked on the link, his money was transferred to the hacker’s account.
The above three are the CSRF attack methods commonly used by hackers.
Of course, if the user is logged in to the bank, the server will send a certain amount of money to the hacker’s account when any of the above three CSRF attacks occur.
At this point, I’m sure you already know what a CSRF attack is. Unlike XSS, CSRF attacks do not require the injection of malicious code into a user’s page, but simply exploit the vulnerability of the server and the user’s login status to carry out the attack.
How do I prevent CSRF attacks?
First, let’s summarize some of the prerequisites for a CSRF attack
- The target site must have CSRF vulnerability; That is, there is no perfect authentication or secondary confirmation.
- The user must have logged in to the target site and remain logged in to that site on the browser.
- Requires the user to open a third-party site.
It can be noted that, unlike XSS attacks, CSRF attacks do not inject malicious scripts into the page, so hackers cannot obtain user page data through CSRF attacks.
The most critical point is to be able to find the server request vulnerability, so our main protection against CSRF attacks is to improve the security of the server.
Several ways to improve server security:
1. Use the SameSite property of the Cookie
When setting cookies in the HTTP response header, take the SameSite option to prevent third-party sites from using cookies.
The SameSite option usually has Strict, Lax, and None values.
- Strict is the strictest. If the value of SameSite is Strict, the browser completely disallows third-party cookies. In short, if you access nuggets from baidu’s page, and some of nuggets’ cookies are set to SameSite = Strict, they will not be sent to Nuggets’ server. These cookies are only carried when you request nuggets from the nuggets site.
- Lax is a little looser. In the cross-site scenario, cookies are carried both by opening a link from a third-party site and by submitting a Get form from a third-party site. However, if you use the Post method in a third-party site, or if you load urls through tags like IMG or IFrame, these scenarios do not carry cookies.
- Using None sends Cookie data in any case.
The severity levels are all no third parties allowed > Only GET requests allowed > All
How to use SameSite specifically, refer to the link (rest assured that there is no CSRF attack, as if CSRF PTSD)
2. Verify the source site of the request
When using post requests, the HTTP header has its own origin field, and the server knows through the ORIG which third party site the request is from and can whitelist it for filtering.
3. CSRF Token
Simply put, cookies are not secure. You can manually set a status field, which is carried by the browser when it requests page data, and carried by the request field when it requests key data. Because CSRF does not have access to user page data, the request is guaranteed to be valid. Even if a hacker sends a request through CSRF, the server will reject the request because the CSRF Token is incorrect.
conclusion
- CSRF attack conditions are met:
- The target site has vulnerabilities
- The user must have logged in to the target site
- Hackers need to use third-party sites to launch attacks.
- Ways to defend against CSRF
- Take advantage of the SameSite property of cookies
- Verify the source site of the request
- Use CSRF Token
- XSS and CSRF vulnerabilities occur because the browser’s same-origin policy opens two loopholes: the ability to reference any third-party resource in the page and the ability to make XMLHttpRequest and Fetch request resources across domains through the CORS policy. This leads to XSS and CSRF, as debug, introducing HttpOnly mechanisms to prevent third-party resources from sending some critical cookies, and SameSite and Origin to prevent CSRF cross-domain requests.
– END –