What is Cross-Site Request Forgery Test?
Cross-Site Request Forgery (CSRF) testing is the procedure of finding and remediating CSRF vulnerabilities in web applications. A CSRF attack tricks users into submitting a malicious request. By performing a CSRF attack, the attacker inherits the identity and privileges of the victim to perform an undesired function on behalf of the victim. For most sites, the browser requests automatically include any credentials associated with the site. If the user is currently authenticated to the site, the site will have no way to distinguish between a legitimate and a forged request.
Testing for cross-site request forgery can be conducted either manually or by using automated tools.
In this article you will learn:
- What is Cross-Site Request Forgery Test?
- What impact can a CSRF attack have?
- How does a Cross-Site Request Forgery attack work?
- Manual testing for Cross-Site Request Forgery vulnerabilities
- Automated Tools for CSRF testing
- Conclusion
What impact can a CSRF attack have?
With no protection from this attack, cross-site request forgery can expose and compromise the confidentiality and integrity of the application’s userdata.
In many cases, a CSRF attack violates how the website handles it’s sessions. This translates to attackers being able to hijack a user’s session in order to perform actions that the user did not intend to take. As an example, an adversary can trick a user into changing their account password to a password of the attacker’s choosing, or change the shipping address to an address the attacker controls without the user’s knowledge or permission resulting in the loss of the trust of end-users.
How does a Cross-Site Request Forgery attack work?
There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for the victim to execute.
Let’s consider the following example:
A user wants to transfer $50 to a friend. The bank application is vulnerable to CSRF. The attacker wants to trick our user into transferring the money to his account instead of the friend’s account. To do that, the attacker needs to:
- Build an exploit URL or script
- Trick the user into executing the action with social engineering
GET Scenario
If our bank application was designed to use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:
GET http://vulnerable-bank.com/transfer.do?acct=Nedim&amount=50 HTTP/1.1
The attacker first constructs the following exploit URL which will transfer $50,000 from the victim to the attacker’s account. The attacker manipulates the original command URL and replaces the beneficiary name and the transfer amount:
http://vulnerable-bank.com/transfer.do?acct=ATTACKERNAME&amount=50000 HTTP/1.1
Via social engineering, by sending the victim an email with HTML content or perhaps by including the exploit URL on another page for example, the attacker can get the unassuming victim to load their URL
A real life example of CSRF attack on an application using GET was a uTorrent exploit from 2008 that was used on a mass scale to download malware.
POST Scenario
Let’s assume that our bank uses POST for transferring parameters and executing actions. The vulnerable request would look like this:
POST http://vulnerable-bank.com/transfer.do HTTP/1.1acct=Nedim&amount=50
Such a request can be delivered using a form tag:
<form action="http://vulnerable-bank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="Filip"/>
<input type="hidden" name="amount" value="50000"/>
<input type="submit" value="View my pictures"/>
</form>
This form relies on the user clicking the submit button, but it can also be executed automatically using JavaScript:
<body onload="document.forms[0].submit()">
<form...
Other HTTP methods
APIs in modern web applications frequently use other HTTP methods, such as PUT or DELETE.
Now let’s assume that our vulnerable bank application uses PUT that takes a JSON block as an argument:
PUT http://vulnerable-bank.com/transfer.do HTTP/1.1
{ "acct":"Nedim", "amount":50 }
We can execute this request by using JavaScript embedded into an exploit page:
<script>
function put() {
var x = new XMLHttpRequest();
x.open("PUT","http://vulnerable-bank.com/transfer.do",true);
x.setRequestHeader("Content-Type", "application/json");
x.send(JSON.stringify({"acct":"Nedim", "amount":50}));
}
</script>
<body onload="put()">
Thanks to the same-origin policy restrictions, this request will not be executed by modern browsers. This restriction is enabled by default unless the target website explicitly opens up cross-origin requests from the attacker’s origin by using CORS with the following header:
Access-Control-Allow-Origin: *
Manual testing for Cross-Site Request Forgery vulnerabilities
If you want to discover if the session is insecure you will need to examine the application’s session. If session management is on the user side, indicating information is available to the browser, then the application is vulnerable. “Client-side values” refer to HTTP authentication credentials and cookies.
Accessible resources via HTTP GET requests are undoubtedly vulnerable, although POST requests tend to be automated via JavaScript and are exposed and vulnerable, therefore the use of POST only is not enough to fix the occurrence of CSRF vulnerabilities.
Automated Tools for CSRF testing
1. Bright
Bright is a Dynamic Application Security Testing (DAST) scanner. It can be integrated across the development pipelines to test your web applications and APIs, automating and simplifying the detection and remediation of CSRF and many other vulnerabilities
By shifting DAST scans left and integrating them across the CI/CD, developers and application security professionals are able to detect vulnerabilities as early as possible, to remediate them before they hit production. This allows developers to adopt the solution and use it throughout the software development lifecycle – SDLC.
Bright’s CSRF test first checks if there is any CSRF protection implemented, by checking if the target has “Access-Control-Allow-Origin” header misconfiguration or missing “Origin” header. The second phase checks if the CSRF token itself is missing inside the request query. If all these steps are confirmed, the final step executes the requests, confirming and validating the vulnerability has been successfully exploited, to ensure there are no false positives.
2. OWASP ZAP
OWASP ZAP is an open-source web application security scanner, used predominantly by professional penetration testers. A great tool but not developer friendly.
ZAP detects anti-CSRF tokens solely by attribute names – that is considered to be anti CSRF tokens and is configured using the Anti CSRF in options. When ZAP detects these tokens it records the token value and which URL generated the token.
3. CSRF Tester
CSRF Tester is a project by OWASP, created by a group of developers for developers, to verify the integrity of HTTP requests in their web applications. CSRF Tester provides a PHP library and an Apache Module for cautious mitigation.
4. Pinata-csrf-tool
Intended to be used by advanced application security professionals. It generates the proof of concept CSRF HTML given an HTTP request to automatically discover whether it is a GET or a POST request with further validation for standard POST and Multipart/form POST. The tool creates HTML corresponding to the type of the request.
Conclusion
Many tools on the market can help you discover and remediate CSRF vulnerabilities but the question is how reliable and developer friendly they are.
With Bright you can easily test for CSRF, the OWASP Top 10 vulnerabilities and many more in just a few clicks. Bright is built from the ground up to put security testing into the hands of developers, integrated seamlessly into their environment and across the CI/CD.
Bright’s automatic validation of every exploitable vulnerability it detects removes false positives and the alert fatigue that comes with it. Developers get immediate results with developer friendly remediation guidelines to prioritise and fix the security vulnerabilities before they hit production. The security team also gets an accurate snapshot of their cyber posture without the need for manual validation, removing the largest bottleneck organisations face currently.
Want to see Bright in action? Get a free account here – https://app.brightsecurdev.wpenginepowered.com/signup
