Hackers can sit at website A and seduce users to attack site B and other site C.
In the Romance of the Three Kingdoms, talented military masters who have the talent of manipulating their thoughts sit in stubbornly determined stubbornly thousands of miles away.
This article will explain how hackers attack and also guide you on how to prevent them.
The fundamental of CSRF
CSRF’s full name is Cross-Site Request Forgery (Another name is XSRF). This vulnerability is quite common, and Netflix and Youtube have also been victims of vulnerability.
The consequences caused by it are also “quite” serious, so CRSF is pleased to be in the top 10 of OWASP security vulnerabilities.
The operating principle of CRSF is straightforward. In the previous article, we learned that the server would store cookies on the user side to distinguish them. Every time a user sends a request to a certain domain, a cookie will be sent.
- First, the user must log in to the page they need (Temporarily called site A).
- To seduce users, hackers will create a malicious website.
- When a user accesses this malicious web, a request will be sent to the A site that the hacker wants to attack (via form, img, …).
- Because ,there is a cookie attached to the user in this request, site A will mistakenly believe that this is a request made by the user.
- Hackers can impersonate users to do actions such as changing passwords, transferring money, …
Common types of attacks
Type 1. Use forms
Once upon a time, there were two brothers from this family named A and B.
One day, arguing with his wife, A was so sad he wanted to leave for the massage. Unfortunately, they asked to ask for the address no one gave because A credit was too low.
Knowing that B is a VIP member, A begged B, to lend the account, but because he was afraid he was spoiled, B refused to let him. What a good brother !! Frustrated, A decided to use the CSRF error to steal B’s account.
Let’s take a look at the HTML of the password change form. This form consists of 2 fields, password, and password_confirm.
A fake a JAV website, pretend to send it to my brother. On the web page, there is a hidden form with the same values as the one above.
B blankly accidentally entered the link and clicked the button. A password change request is sent to the PO*NH**, accompanied by B’s cookie account.
It’s done! A only needs to use email + new password 123456 to log into his brother’s account.
Type 2. Use img tag
The story is not over yet. There is a massage place, but his wife holds the money; a does not have money to do the massage. A decided to hack B’s bank account.
Using JAVBank. Each time you make a transfer, the bank will create 1 URL. Suppose person A wants to pass 1000 to person B; the generated URL will be of the form http://jav.bank?from=Person1&to=Person2&amount=1000.
Remove this URL into 1 img tag. When B visits the page, the browser will call GET request, attached to a cookie on JAVBank of B. Through the cookie, the bank confirms it is B, transfer money to A.
Note
Of course, the article is just an example. As a rule, GET requests are only used to access data, not perform data change operations such as edit/delete.
Banks are often very secure by setting cookies with a relatively short lifespan, not allowing money transfers without OTP code, etc.
Also, p*****b also has good security measures (see below), so you can’t use this to steal your friends’ accounts, don’t give it a try!
However, in the old days, when security vulnerabilities were not widespread, this was exactly how hackers used it. Just post a picture containing the above link on a certain forum, there will be countless people trapped when accessing that forum.
Prevention for website
Here are some basic ways to prevent CSRF:
- Use CSRF Token: In each form or request, we attach a CSRF token. This token is created based on the user’s session. When sending to the server, we check the authenticity of this session. Because this token is randomly generated based on session, hackers cannot fake it (frameworks like RoR, CodeIgniter, ASP.NET MVC all support CSRF token).
- Check the Referer and Origin values in the header: Origin tells us the website calls this request. This value is included in each request and cannot be edited by the hacker. Check for this value; if it is a strange page, then do not process the request.
- Check the X-Requested-With: Request header that contains this header is a secure request because this header prevents us from sending requests to other domains (details).
- Be careful to prevent XSS errors: With XSS, hackers can install malicious code on the website to attack. At this point, all anti-CSRF methods such as tokens, referrers are disabled.
Conclusion
In the old days, this bug was quite serious and common. Recently, frameworks are mostly defaults against this error, so they encounter less frequency. However, we still have to be careful, especially the websites that code themselves (especially PHP code).
Also, as a user, you need to know how to protect yourself in the following ways:
Sign out of your account after using it to avoid saving cookies.
Don’t click ads or random buttons.
Do not visit obscene or dangerous sites. As mentioned above, sometimes we do not press anything, visit the page, the browser will automatically post based on javascript or the img tag.
