Cross-Site Request Forgery, also known as Session Riding or One-Click attack, and abbreviated to CSRF or XSRF, is a type of attack that exploits the user’s identity and privileges to execute unintended actions on a web application.
CSRF lets attackers partly bypass the same-origin policy (SOP) and cross-origin resource sharing (CORS) security mechanisms implemented by most web browsers. Broadly, SOP permits requests coming only from the same origin while CORS permits only specified types of requests from a different origin. These measures prevent unauthorized cross-site access; that is, different web applications interfering with one another.
What Is Cross-Site Request Forgery?
Cross-Site Request Forgery occurs when an attacker sends a well-curated, yet malicious, HTTP request to a web application that a user has already authenticated against (logged into). The attacker takes advantage of the trust the web application has with the authenticated user to send a valid request to the target application without the user’s explicit consent.
A web application that cannot differentiate between legitimate requests and forged requests could be vulnerable to CSRF attacks. In CSRF, the attacker submits forged requests to the target web application, via the target’s browser, and performs a function without the victim’s knowledge.
Differences Between CSRF And XSS Attacks
CSRF attacks are often confused with XSS (Cross-Site Scripting) attacks. Both attacks have some similarities, such as they are client-side attacks and require the user to complete an action like clicking a nefarious link or visiting a site. However, some subtle characteristics differentiate XSS and CSRF attacks.
XSS occurs when the attacker injects and executes a malicious script (usually in JavaScript) within the victim’s web application. Unlike CSRF, XSS does not require an authenticated session. In XSS, the user’s trust for a web application is exploited.
On the other hand, CSRF lures a victim to complete actions that they do not want to. In CSRF, the web application’s trust for a user is exploited.
Furthermore, CSRF is limited to the privileges the user can perform. However, since XSS depends on the execution of a script, this expands the scope of activities the attacker can undertake.
What Is The Impact Of A CSRF Attack?
CSRF is a dangerous vulnerability that can lead to devastating state changes on the server of the target web application. The extent of its impact depends on the level of privileges assigned to the user.
For example, suppose the victim is a normal user. In that case, the attacker could lure them to carry out state-changing requests like updating their email address and password, transferring funds, or performing any other undesired action. If the compromised user has an administrative account, the attacker could bring the entire web application to its knees.
How Does CSRF Attack Work?
CSRF attacks leverage how web applications manage user authentication. Most web applications use cookies to identify logged in users. Once a web server has authenticated a user successfully, the browser will get a unique identity login cookie representing the user’s current session.
The cookie is used to remember the user’s logged-in status, without requiring them to authenticate for every page they visit within the application. The session will be removed when the user logs out of the web application, or they close the browser. An attacker can abuse this mechanism to compel the browser to carry out some malevolent actions that the user does not intend to do.
CSRF Attack Example
Let’s say Alice regularly uses a fictitious online banking account called someexamplebank.com to send Bob $1,000 each month. Sadly, Alice does not know that someexamplebank.com is vulnerable to Cross-Site Request Forgery attacks.
Meanwhile, an attacker, Chuck, intends to exploit this vulnerability and trick Alice into sending the cash to him, instead of to Bob.
The following conditions should be met to execute the attack successfully:
- Chuck should create an exploit URL. The URL should be valid and capable of causing a state-changing effect to the target web application.
- Chuck should lure Alice into clicking the malicious URL.
- Alice should have an active authenticated session with someexamplebank.com.
Let’s look at how the attack could play out, using either a GET scenario or a POST scenario.
a) GET request
Let’s say that the online banking account uses the HTTP GET request method to transfer funds. As such, Alice’s request to transfer $1,000 to Bob could look something like this:
According to the first condition of launching CSRF attacks successfully, Chuck needs to create an exploit URL that will transfer money from Alice’s account to his account.
Chuck takes the original request URL and substitutes the beneficiary name with himself, while also significantly increasing the transfer amount:
Next, Chuck needs to trick Alice into clicking the above malicious URL. Chuck can use various social engineering techniques to lure Alice into executing the URL when she’s logged into the web banking application.
These are the common techniques he can use:
- Embed the exploit URL into HTML content and send it to Alice through email.
- Embed the URL on pages that Alice often visits while logged into the banking application.
The malicious URL could be disguised as a normal link, encouraging Alice to click it:
Or, it could be disguised as a fake image:
If the above image tag were included in the attacker’s email to Alice, she could fall prey to the attack. If Alice clicks it, her browser opens the URL automatically—without her even realizing it.
So, without Alice’s consent, a malicious request is sent to someexamplebank.com. If Alice has an active session with the online banking application, it would treat the request as legitimate and transfer the specified amount to the attacker.
b) POST request
If the online banking application uses the HTTP POST request method to transfer funds, it’s impossible to deliver the malicious requests using <a> or <img> tags.
However, the crafted request can be delivered using a <form> tag. The attacker can also use JavaScript to specify that the form should be executed automatically.
Here is how the code for the form may look like:
How To Prevent CSRF Attacks
You can implement different techniques to strengthen your web application’s security and assist in lowering the possibility of Cross-Site Request Forgery attacks.
Let’s discuss some of them.
1. Practice user education
You can educate your users to safeguard their login credentials and deny unauthorized persons from gaining entry into applications.
These are some best practices you can teach them:
- Keep web browser versions up-to-date.
- Avoid permitting browsers to remember usernames and passwords.
- Avoid browsing other sites while simultaneously logged into sensitive applications.
- Log off web applications after completing using them.
- Keep usernames and passwords secure.
2. Implement advanced validation
You should protect your web application by implementing measures beyond basic user authentication. After all, the malicious request comes from the user, without them even knowing of it. Therefore, it’s essential to authenticate both the user and the request. This will help you to know whether the request is legitimate or forged.
These are some techniques you can use to implement advanced validation:
- Produce unique, unpredictable random CSRF tokens for each session request. The token can be included in hidden fields, added within forms, or incorporated in headers. If the web server identifies that a session request does not match its token, the token is duplicate, or the token is misconfigured, then the request is prevented from accessing the application.
- Use the sameSite cookie attribute available in most modern browsers to invalidate requests originating from unauthorized locations. This attribute allows you to instruct the browser to send cookies along with cross-site requests only if certain conditions are met.
- Implement double submission of cookies. In this strategy, a random, unique value is allocated to both a request and a cookie parameter. The server then confirms whether the request value and the cookie value match before allowing access to the web application.
3. Conduct regular security tests
It’s critical to constantly scan and test your web applications to detect any emerging CSRF threats. By being proactive, you can substantially reduce the likelihood of attacks.
These are some open source security tools you can use to identify CSRF vulnerabilities in your web applications:
- The OWASP CSRFGuard is a great tool for mitigating the risks of CSRF attacks. It allows you to automatically detect flaws that could make your web application vulnerable to CSRF attacks.
- The OWASP CSRF Protector Project is another powerful tool that can help you to secure your web applications against CSRF attacks.
Conclusion
Cross-Site Request Forgery (CSRF) attack is one of the serious threats to web applications. The vulnerability is based on the manner the HTTP protocol handles the normal web requests and responses.
In a CSRF attack, the intruder forces a user to complete unwanted actions on a reliable web application, without the user’s knowledge. So, its effects can be devastating. Nonetheless, you can implement sufficient measures to safeguard your applications from this type of attack.
