What Is Cross-Site Request Forgery (CSRF)؟
Have you ever encountered strange and suspicious files and links? You have probably heard by now that you should not click on such links or download files! One of the reasons is CSRF vulnerability or bug. CSRF stands for Cross-site request forgery, one of the most dangerous attacks on the server side boatsman Another, also known by other names, is a targeted and intelligent attack on sites with an authentication system that even famous services such as YouTube have suffered. In the following, we will introduce and examine this vulnerability in more detail and how to prevent it.
What is a CSRF vulnerability?
We saCross-Sitee term CSRF stands for Cross-Site Request forgery, which means request forgery attacks. This bug or vulnerability is known as sea surfing, XSRF, see-e-click, hostile linking, and one-click attacks. As we said, this vulnerability is on the server side, and most websites with an authentication system, such as banking services, online shops, educational centers, etc., suffer from this attack.
In this type of attack, the attacker uses the CSRF vulnerability to force users to take; inions that the attacker wants; in fact, the attacker sends his request to the server with the help of the victim user. This vulnerability allows attackers to bypass the SOP (Same origin policy) policies.
What are the effects of the CSRF attack?
In CSRF attacks, the attacker can force the victim user to perform unwanted actions, and based on the level of application performance and the access level of the victim user, he can cause further damages, which we will describe a few cases:
At a superficial level, with the help of CSRF vulnerability, the attacker can change the victim users’ password, email, etc.,
In websites where users can publish content, the attacker can publish the desired content with the victim’s account.
In banking applications with this vulnerability, the attacker can transfer money with the account and identity of the victim user.
Depending on the level of the victim user, the attacker can perform different actions; for example, in the case of a high-level user, he can also change the application information.
How does a CSRF vulnerability work?
For a CSRF vulnerability attack to be possible, there are three critical conditions that we will consider:
Favorable action for the attacker
Some possible actions on websites on some data, such as changing email, password, etc., are desirable for attackers in this field, and they have reasons for doing them.
Session management based on cookies
Performing some actions requires sending an HTTP request. If the website only depends on cookies to identify the user and has no other way to identify and validate the user session, a CSRF attack is possible.
The possibility of predicting request parameters
It was said that some website actions are done with the help of links. Request parameters should not be specified to avoid a CSRF attack. For example, for the request to change the day, the attacker can quickly attack if the relevant parameter shows the user’s current password.
What are the types of CSRF vulnerabilities?
CSRF vulnerabilities are divided into three categories according to how they are implemented. Of course, in most exposures, the attacker uses the victim user to complete their attack with the help of social engineering techniques.
GET method scenario
In this scenario, the attacked website uses the GET method for critical operations, such as transferring money and changing account information. This method, along with authentication based on cookies and…, is one of the biggest mistakes that makes CSRF vulnerable. In this method, the attacker uses social engineering techniques to direct the victim to send a fake request. The attacker traps the victim with the help of link codes, tags, and tempting texts. Ultimately, the attacker completes his attack by clicking on the desired link, using the GET method, and sending a request with cookies. To better understand this scenario, read the following example.
Example: In a banking application, the attacker wants to deposit five million tomans to the hypothetical card number 6037, and after determining the amount and the recipient’s card number, he clicks on the transfer option, and his request is sent. In the GET method, the URL code has a specific pattern. For example, the card number is displayed with the acct template, the amount is said with the amount parameter, and authentication is done based on cookies. Therefore, if the attacker enters the desired card number instead of the destination card number and the victim enters the desired page, the amount will be deposited into the selected account of the attacker. Suppose the URL is like the following example:
http://bank.com/transfer.do?acct=6037&amount=3000000
Now, the attacker can send his fake link to the victim with his techniques and linked link, and after the victim clicks on the link, he sends the request with the GET method and with the help of a bank cookie, and the amount is deposited into the attacker’s desired account. An example is the following link:
<a href http://bank.com/transfer.do?acct=6037&amount=3000000 Click here!</a>
Of course, this method is mainly used for cases where the attacker can only send a text and a link, such as text messages and the comment section of websites. Sometimes, the attacker can use fake tags like <Img>. In these cases, by opening the page of this code, the victim’s browser automatically sends the attacker’s request to open the image to the bank’s website. The request is sent with the GET method, and the victim user does not see the bank site or idea. In this case, the length and width of the image are set to zero. Its link is something like the following link:
<img src=”http://bank.com/transfer.do?width6037&amount=3000000″ width=”0″ height=”0″ border=”0″>
An actual example of a CSRF attack in the GET method
On January 17, 2016, on the HackerOne site (the famous Bug Bunty platform), a report was filed by a penetration testing expert from WeSecureApp about the existence of a vulnerability in one of the Twitter-related domains named Shopify at the address twittercommerce.shopifyapps.com. This domain was created to connect the users of the store owner and the ability to remove the Twitter account linked to that platform. The expert found that it is possible to log out of the report with the get method and the following URL
POST method scenario
It turned out that the GET method is hazardous for important actions, but the following POST method is more secure against attacks, like the previous example. However, the POST method also leaves ways to abuse the CSRF vulnerability. To better explain this vulnerability, we use the following example:
Consider a website with the fictitious name com. site that allows users to change their email addresses. When requesting to change the email, the request is sent with a particular Http pattern, which includes all the things needed to exploit the CSRF vulnerability, such as the use of cookies to identify the user, the email change action that is suitable for this type of attack, and the ability to detect parameters in the link. has it. For example, the following code:
POST /email/change HTTP/1.1 Host: Site.com Content-Type: application/x-www-form-urlencoded Content-Length: 30 Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE email= ….com
An actual example of a CSRF attack in the POST method
On August 9, 2015, a csrf vulnerability related to the Instacart website was reported. This platform, a grocery store with the possibility of online purchase and product delivery, has product senders of specific regions, and orders related to each area are assigned to them. The expert realized that the product in the panel of senders with the following link is vulnerable to CSRF attacks, that with a particular HTML command, the attacker could find out the sender’s activity after the link is opened and change it without the vulnerable site finding out. The scenario of other methods
In other methods, the vulnerability of CSRF is not as high as in the previous two scenarios. However, it is still possible, for example, to transfer money in the PUT method if the information is in JSON format and authentication is done through cookies; the attacker can create a kind of XHR command to make a fake request from the user and By opening it in the browser, the money will be transferred automatically. Of course, this method is not usually used in applications, and the probability of vulnerability is very low. Still, it is better to be familiar with it to change the filters if needed.
Prevent CSRF attacks
Many methods are used to prevent CSRF attacks; we will examine two of the most common ones.
CSRF tokens
There are different ways to prevent attacks, but the most reliable way is to put the CSRF token invalid requests, which must have certain features; The token should be unpredictable and random, have a one-to-one relationship with the user session, and be validated before any action. But another way to increase security, which is better to use along with the CSRF token, is to use Samesite in user session cookies.
Of course, using tokens does not entirely prevent attacks; It may be interesting to know that the origin of many CSRF vulnerabilities is mistakes that occur in CSRF token validation. Follow the article below to check the reasons for this:
CSRF token validation depends on the request method
Sometimes, when using the POST method, the validation is done correctly, but in the GET method, the proof is not done correctly; In these cases, the attacker uses the GET method to bypass the verification to carry out his attack.
CSRF token validation depends on the existence of the token
On some websites, verification is only performed when the ticket is present; In this case, the attacker bypasses the validation by removing the entire key and executing a CSRF attack.
The CSRF token does not belong to the session of the same user
In some cases, the website does not perform the necessary check for the token belonging; in this case, the website saves all the published tokens and accepts any existing ticket; In this case, the attacker performs his attack by joining the site and casting the actual key and using it as the token of the victim user.
Placing the CSRF token in a cookie other than the session cookie
Sometimes the website puts the token in the session cookie, but not necessarily the cookie used to track the user! This is possible when the website uses two frameworks for CSRF protection and session management.
The CSRF token is only copied into a cookie.
Some websites do not store the cookies they issue on the server side, but each token is placed in the cookie and the request parameter. In these cases, during validation, it is only checked that the value of the ticket in the cookie and the registered pass are the same. In this way, the defense solution (Double Submit) against CSRF is called, which is widely used due to its easy implementation.
Use Referer to avoid CSRF.
In addition to using a token, some websites use the Referer header in HTTP requests to defend against CSRF attacks. This is usually done to ensure requests are sent from their domain, which is easy to bypass. There are many reasons why this method does not provide sufficient security:
Referer validation depends on its header
Some websites only validate it when the Referer header is removed from the request. In this situation, the attacker can design his CSRF exploit to remove the Referer header from the request. There are many ways to do this; the easiest way is to use the META tag in the HTML page hosting the CSRF attack.
Ability to bypass Referer validation!
On some websites, the Referer header validation is not done carefully enough and can be bypassed. For example, suppose the target website only checks that the domain in the referrer starts with the same valid environment. In that case, the attacker can fetch the right setting as a subdomain of its territory and attack the website.
What are CSRF vulnerability detection tools?
So far, we have learned about common types of CSRF vulnerabilities and some ways to increase security against such attacks; But there are tools to discover this vulnerability more precisely. These tools should analyze requests and responses as a kind of internal proxy. One of the advantages of these tools is the ability to change the request and view the replies in raw form. Following are the names of some CSRF vulnerability detection tools:
- Postman
- Burp suite
- Fiddler
In this article, we learned about the attacker’s methods to use the CSRF vulnerability in different ways, such as GET. Also, techniques such as using CSRF tokens to increase security were said that website owners should pay attention to them so that they and users will have fewer problems. But perhaps the most straightforward yet vital takeaway from the article’s information is not to click on anonymous links. It should also be noted that by knowing the vulnerability of CSRF, you can work on the portals related to Bugbunty and earn money by discovering these vulnerabilities. I hope the article has helped you to get more information and increase security. Please share your comments and questions with us.
