What is CSRF (Cross-Site Request Forgery) attack and how it works?
Cross-Site Request Forgery (CSRF) is a type of web security vulnerability that allows an attacker to carry out unauthorized actions on behalf of a victim user by exploiting the trust relationship between a user and a website. CSRF attacks typically occur when a user is logged in to a website and the attacker tricks the user into clicking a malicious link or visiting a malicious website.
What is a real world example of a CSRF attack?
Here is an example of a CSRF attack code that targets a simple web application that allows changing a user’s email address through a HTTP GET request:
<html>
<body>
<h1>Change Email Address</h1>
<form action="http://example.com/update_email" method="get">
<input type="hidden" name="email" value="attacker@example.com" />
<input type="submit" value="Change Email" />
</form>
</body>
</html>In this example, the attacker creates a malicious website that includes a form that targets the vulnerable web application at http://example.com/update_email. The form includes a hidden input field named “email” that contains the attacker’s email address, which will be submitted as the new email address for the victim user.
When the victim visits the malicious website and clicks the “Change Email” button, their web browser sends a GET request to the vulnerable web application with the attacker’s email address as a parameter. Because the request appears to come from the victim user, the web application assumes that it is legitimate and updates the user’s email address to the attacker’s email address.
CSRF Attack Example to Steal Session Cookies
Here’s an example of a CSRF attack code that targets a website to steal session cookies:
<html>
<body>
<h1>Click to View Cute Kittens!</h1>
<img src="http://www.example.com/cute-kittens.jpg" width="300" height="200" />
<form action="http://www.example.com/logout" method="GET" id="logout-form">
<input type="submit" value="Logout" />
</form>
<script>
// This script will automatically submit the logout form to steal the user's session cookies
// when the user clicks the "View Kittens" link
window.onload = function() {
var form = document.getElementById('logout-form');
form.submit();
}
</script>
</body>
</html>
In this above mentioned example of CSRF attack to steal web application session cookies, the attacker creates a fake website that includes a link to view cute kittens, but also includes a hidden form that logs the user out of the target website when the page loads. When the user clicks the link, the JavaScript code automatically submits the logout form, which steals the user’s session cookies and sends them to the attacker’s server.
7 CSRF Attack Prevention and Mitigation Techniques to secure applications vulnerabilities
- Token Synchronization
- Double-Submitting Cookies
- Same-Site Cookies
- Enabling User Interaction
- Custom Headers for Requests
- Use of Captcha
- Use Referer header
CSRF Mitigation Technique #1: Token Synchronization
Token Synchronization is a CSRF attack mitigation technique that involves generating and validating a unique token for each user session to prevent unauthorized requests. The token is typically included in a hidden form field or in a custom HTTP header, and is verified by the server before processing the request.
How Token Synchronization works to mitigate CSRF attacks?
Token synchronization is a technique used to prevent CSRF attacks by adding an extra token to each form that is submitted. This token is then checked by the server to ensure that the request was generated by the same user who originally requested the form.
Here’s how token synchronization works:
- When a user requests a form, the server generates a random token and includes it in the form as a hidden input field.
- When the user submits the form, the server checks that the token included in the request matches the token that was originally generated for the form. If the tokens match, the server accepts the request as legitimate and processes it. If the tokens do not match, the server rejects the request.
- When the server sends a response to the user, it includes a new random token that will be used for the next request.
Token Synchronization is effective in mitigating CSRF attacks because it ensures that requests can only be made from a valid user session. This means that even if an attacker can generate a request that looks like it comes from the user, they will not have the correct token and the request will be rejected. By using token synchronization, the server can ensure that a request came from an authenticated user and was not generated by an attacker. The attacker cannot predict or guess the correct value of the token since it is generated randomly for each form.
Generates Unique Token
When the user logs in to a website, a unique token is generated for their session.
Custom HTTP Header
The token is included in any forms or requests sent by the user, either as a hidden field or in a custom HTTP header.
Token Match
When the server receives the request, it checks that the token matches the one generated for the user’s session.
Check and Validate Token
If the token is valid, the server processes the request as normal. If the token is invalid or missing, the server rejects the request and does not perform the action.
Token Synchronization is effective in mitigating CSRF attacks because it ensures that requests can only be made from a valid user session. This means that even if an attacker can generate a request that looks like it comes from the user, they will not have the correct token and the request will be rejected.
One of the benefits of Token Synchronization is that it is a relatively simple mitigation technique to implement. However, it does require developers to modify their applications to generate and validate tokens for each user session. Additionally, if tokens are not properly synchronized or are easily guessable, they can be vulnerable to brute-force attacks. Therefore, it is important for developers to properly design and test their token synchronization implementation to ensure its effectiveness in mitigating CSRF attacks.
CSRF Mitigation Technique #2: Double-Submitting Cookies
Double-Submit Cookies is a technique used to mitigate CSRF attacks by creating and validating two cookies with the same value but different names.
How Double-Submitting Cookies mitigate CSRF attack?
Here’s how Double-Submit Cookies work to mitigate and prevent CSRF attack:
- When the user logs in, the server generates a session ID and sets two cookies:
- “sessionID” cookie contains the session ID.
- “csrfToken” cookie contains a random token, such as “ABCDE12345”.
- When the user submits a form, the server checks that the values of both cookies match. For example, the form might contain the following hidden input fields:
<form method="post" action="/submit-form">
<input type="hidden" name="csrfToken" value="ABCDE12345">
<input type="hidden" name="data" value="some data">
<input type="submit" value="Submit">
</form>When the server receives the request, it checks that the “csrfToken” value in the request matches the “csrfToken” value in the cookie. If the values match, the server accepts the request as legitimate and processes it. If the values do not match, the server rejects the request.
When the server sends a response to the user, it includes new values for both cookies, so that the next request will include updated values. For example:
Set-Cookie: sessionID=12345; Path=/
Set-Cookie: csrfToken=FGHIJ67890; Path=/
This ensures that the values of the cookies change with each request, making it difficult for an attacker to guess or predict the correct values.
By using Double-Submit Cookies, the server can validate that a request came from an authenticated user and was not generated by an attacker. The attacker cannot set the values of both cookies to the correct values since they cannot access or modify the legitimate “csrfToken” cookie.
