This is the second installment in a series on Web Application Vulnerability Basics.
What Is Cross-Site Request Forgery?
Cross-Site Request Forgery, also known as CSRF and XSRF, is a web application attack that tricks a victim into submitting a malicious request to a web app that they are currently authenticated to. Since the victim is authenticated, the malicious request appears to be a legitimate request from the victim. The victim is usually unaware of the attack, and CSRF can easily go unnoticed. A CSRF attack is most commonly exploited using cross-site scripting but can also be triggered by a malicious phishing link or email.
This can allow for an attacker to change the victim’s passwords, make purchases, initiate bank transfers, and much more, all appearing as legitimate requests from the victim. If the victim is a privileged user, attackers can use CSRF to create new accounts, modify and exfiltrate sensitive data, and lead to a complete compromise of the web application.
How does CSRF Work?
Some web applications use cookies and other identifying information to maintain an authenticated session when a user is logged in, and browsers will include this info when sending requests to the app. CSRF takes advantage of this by tricking a user into sending a malicious request to the web app, and since the browser includes the session identifying information the web server sees the request as a valid request by the user. Therefore, a CSRF attack enables an attacker to create, delete, modify, or remove data in a web app on behalf of the victim, without their knowledge.
For example, a victim is logged into mywebapp and an attacker is trying to change their password via CSRF. The attacker can craft a request that will change the password of the user that is currently logged in, which looks like the following: <pre>mywebapp/settings?newpassword=1234</pre>. The authenticated victim is then tricked into clicking on the link, and the web server will execute the password change. If an attacker already has executed a stored XSS attack on the website, the attacker can have the victim’s browser request the crafted CSRF address automatically when the victim views the page, and change the password of any logged in user who views the page.
CSRF Mitigation Techniques
Token-Based Mitigation
Token-based mitigation is the most widely used way to counter CSRF and has proven to be effective. Some frameworks have native support for CSRF Token Mitigation, so make sure to check if one exists before implementing a custom solution. Token-based mitigation solutions are separated into two different groups, stateful and stateless tokens. Use whichever is appropriate for your application and scenario, as both stateful and stateless tokens accomplish the same objective.
Stateful tokens, sometimes referred to as Synchronizer tokens, are generated per user session or request. Tokens are usually stored in a hidden HTML field and passed to the client and when the client makes a request it must include the provided token in the request. This is a fairly easy process to implement and has little impact on the user experience, but very hard to get around using CSRF.
When using stateless tokens, the web server will generate a session ID and a timestamp, and either hash or encrypt the token. The serve distributes the token to the client, and when the client sends a message back to the server it includes the token. Depending on the method used, the server will either decrypt the token and compare it to the stored token or hash the stored token and compare it to the client’s hashed token. If the tokens match, the web server will allow the request.
Other Techniques
There are a few additional mitigation techniques that are used to counter CSRF, but these should not be used as a replacement for token-based mitigation. Use these strategies to enhance the security of token-based mitigation, but not as a replacement.
- Verify the origin of the request header using standard headers
- Use custom request headers
- Employ a robust content security policy to prevent XSS used to execute CSRF attacks
- Require user interaction and reauthentication to execute sensitive requests
Conclusion
CSRF can be a dangerous web application exploit but can be easily mitigated. Ensure that you are protecting against CSRF attacks to protect your users and your application. A great way to verify your protection against CSRF is to employ a NuHarbor Web Application Penetration Test.
Follow us on Social Media for more information:
Twitter facebook LinkedIn instagram
[hubspot type=form portal=9212203 id=78ed4f55-84a0-4cb8-bae7-8d92e16878ab]
