Table of contents
- What is cross-site request forgery?
- How a CSRF attack works
- Preventing cross-site request forgery
- Examples of CSRF attacks
- Testing for CSRF vulnerabilities
Cross-site request forgery, also known as a CSRF attack, is one of the most insidious threats to modern web applications. This type of attack allows a malicious actor to send a fraudulent HTTP request by exploiting the session of an authenticated user.
In this article, we will explore in detail how to prevent cross-site request forgery. We will examine practical examples, mitigation techniques, and testing methods to ensure the security of your business website.
What is cross-site request forgery?
Cross-site request forgery, abbreviated as CSRF, is a type of attack that exploits the trust a web application has for its authenticated user. This attack induces the user to send unwanted HTTP requests without their consent.
Example:
An attacker can create a hidden form on a malicious site that, when loaded by an authenticated user on another site, sends a request to transfer money without the user’s knowledge.
How a CSRF attack works
A CSRF attack relies on some fundamental assumptions:
- The user is authenticated on a web application and has an active session.
- The attacker induces the user to send a fraudulent HTTP request.
- The request is accepted by the application as legitimate because it comes from an authenticated user.
Example of a cross-site request forgery attack
Example:
Imagine a banking website where an authenticated user can transfer money by sending a POST request to /transfer.
An attacker could create a page with a hidden form that executes a similar request:
<form action="https://bank.com/transfer" method="POST" style="width: 0; height: 0;">
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="to_account" value="attacker_account">
<input type="submit">
</form>When an authenticated user visits the attacker’s page, the form is automatically submitted, transferring money without the user’s consent.
Preventing cross-site request forgery
There are various techniques to prevent cross-site request forgery, some of which include:
- CSRF tokens
One of the most effective methods is the use of CSRF tokens. Each time a state-changing request is sent, a unique token is generated and sent along with the request. The server verifies this token before accepting the request. For example, each form could include a hidden field with the CSRF token:
<form action="/transfer" method="POST">
<input type="hidden" name="csrf_token" value="random_token_value">
<!-- other form fields -->
<input type="submit">
</form>- Custom HTTP headers
The use of custom HTTP headers can help prevent CSRF attacks. Legitimate requests include an HTTP header that requests from an external site cannot easily add. - Referer validation
Another technique is referer validation. The application checks that the request’s referer matches the domain of the same application. However, this method can have limitations due to privacy issues and browser configurations.
Examples of CSRF attacks
- Social media platform attack scenario
An authenticated user on a social media platform can be tricked into clicking a malicious link that executes actions on their account, such as sending messages or modifying profile settings. - Money transfer scenario
As described earlier, an authenticated user on a banking website can be tricked into transferring money to the attacker’s account simply by visiting a compromised web page.
Testing for CSRF vulnerabilities
The goal of testing is to identify any weaknesses in the system that attackers could exploit to perform unauthorized actions through authenticated users. Below, we analyze in detail the techniques and tools for effective CSRF vulnerability testing.
CSRF testing tools
There are several tools specifically designed to identify and test CSRF vulnerabilities. Some of the most widely used include:
- OWASP ZAP (Zed Attack Proxy)
One of the most popular open-source web security tools, ZAP is equipped with numerous plugins and functions for testing CSRF vulnerabilities. It can be configured to intercept and modify HTTP requests, simulating potential CSRF attacks.
- Burp Suite
This powerful web security tool offers a comprehensive interface for testing web application vulnerabilities, including CSRF tests. Burp Suite allows for the automation of many testing operations, identifying weak points, and suggesting possible mitigations.
- CSRF-Tester
A specialized tool for testing CSRF vulnerabilities, designed to facilitate the discovery of weak points in web applications. CSRF-Tester allows for the generation of custom HTTP requests to verify if CSRF protections are correctly implemented.
Cross-site request forgery testing techniques
- Verification of CSRF tokens
The first step in CSRF testing is to verify if state-changing requests include a CSRF token. This can be done by observing HTTP traffic during the use of the application. POST, PUT, DELETE, and other data-modifying requests must include a unique CSRF token. If a token is present, it must be validated to ensure that it changes with each session and cannot be easily guessed.
- HTTP request manipulation
Using tools like OWASP ZAP or Burp Suite, you can intercept and manipulate HTTP requests to remove or modify CSRF tokens. If the application accepts the modified request without a valid token or without the CSRF token, it means it is vulnerable to a CSRF attack. It is important to test different variants of the request to cover all possible attack vectors.
- Referer validation test
Some applications use the referer field in the HTTP header to protect against CSRF attacks. During testing, it is important to verify if the request is rejected when the referer does not match the application’s domain. However, this technique has limitations as users can disable the referer for privacy reasons, and some proxies or firewalls may remove or alter the header.
- Use of custom HTTP headers
More advanced applications may require custom HTTP headers in state-changing requests. During testing, verify if the application actually checks these headers and if it rejects requests that do not include them. This method can be tested by sending requests without the required headers and observing the application’s response.
- Creating proof of concept (PoC) CSRF attacks
To demonstrate actual vulnerability, create proof of concept that simulates a CSRF attack. For example, build an HTML page that sends a fraudulent POST request on behalf of the authenticated user. Run the PoC with an authenticated user in the target application to see if the attack succeeds. This technique helps demonstrate the real impact of the vulnerability.
Practical example of CSRF testing
Imagine testing an online banking application to verify if it is vulnerable to a CSRF attack. The money transfer function is a critical area to test. Here are the steps you could follow:
- Intercepting the transfer request
Using Burp Suite, intercept the HTTP request sent when an authenticated user attempts to transfer money. The request might look like this:
POST /transfer
Host: banking.com
Content-Type: application/x-www-form-urlencoded
Cookie: session_id=abcd1234
amount=1000&to_account=123456&csrf_token=xyz789
- Removing the CSRF token
Modify the intercepted request to remove or alter the CSRF token and resend the request to the server. If the server accepts the request without the CSRF token or with an invalid token, the application is vulnerable. - Simulating a CSRF attack
Create an HTML page that sends the same POST request without the CSRF token. Example of an HTML form:
<form action="https://banking.com/transfer" method="POST">
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="to_account" value="123456">
<input type="submit" value="Submit">
</form>
Load this page with a browser where the user is authenticated in the banking application and see if the transfer occurs without the CSRF token.
- Referer validation
Modify the HTTP request to change or remove the referer header and resend the request. If the application accepts the request without a valid referer, it may be vulnerable to CSRF.
- Adding custom HTTP headers
Test if the application uses custom HTTP headers to protect against CSRF by modifying the request to remove these headers and observing if the request is accepted.
FAQ
- What is cross-site request forgery (CSRF)?
CSRF is an attack that induces an authenticated user to send fraudulent HTTP requests without their consent by exploiting their active session. - How does a CSRF attack work?
An attacker creates a fraudulent HTTP request that is sent to a web application through the authenticated user by exploiting the application’s trust in the user. - What are the methods to prevent CSRF?
The use of CSRF tokens, custom HTTP headers, and referer validation are some techniques to prevent CSRF attacks. - What is a CSRF token?
A CSRF token is a unique value generated by the server and included in each state-changing request to verify the request’s authenticity. - How can I test my website for CSRF vulnerabilities?
Tools like OWASP ZAP and Burp Suite can be used to simulate CSRF attacks and verify the robustness of your site’s defenses. - What is a common example of a CSRF attack?
A common example is unauthorized money transfer on a banking website through a fraudulent POST request sent from a malicious site. - How does CSRF affect web browsers?
Web browsers, being the medium through which users interact with web applications, can be exploited to send CSRF requests without the user’s knowledge. - What does “input type submit” mean in a CSRF attack?
“Input type submit” is an HTML element used to submit forms that can be hidden in malicious pages to perform unauthorized actions. - What role does social engineering play in CSRF attacks?
Social engineering is used to trick users into clicking links or visiting malicious pages, thereby triggering CSRF requests. - Why are web applications vulnerable to CSRF?
Web applications are vulnerable to CSRF when they do not correctly implement security mechanisms such as CSRF tokens and referer checks, allowing attackers to exploit authenticated user sessions.
