Cross-Site Request Forgery (CSRF) is when an attacker takes advantage of a logged-in user's authenticated state to execute malicious application requests and change the user's app in harmful ways. Because the attacker can't see the result of any attack, it's usually less about exfiltrating information and more about exploiting the app's capabilities (for example, making the user of a mobile payment system send money to the wrong person). There's often a strong social engineering aspect involved: phishing and other techniques are used to get a user to click on the link that will kick off a malicious request and act as the CSRF attack vector.
CSRF is often possible because authentication credentials or cookies meant for one part of an application mistakenly allow access to another. An example would be that while you're logged into PayPal or another payment app, you click on a link sent to you in a chat session. The link executes code that takes the authentication cookie you have in your browser to make an (authenticated) request sending money to the attacker. Unlike XSS, the danger isn't that you'll send sensitive information to the attacker, allowing them to impersonate or defraud you later; instead, the danger is a direct consequence of the actions you're allowed to take as a logged-in user of the app.
Many frameworks (Spring, Joomla, and Django) have their own solutions for preventing CSRF, which usually consist of tying a cookie's authentication ability to a specific in-app action. But, despite CSRF's status as a solved problem, it persists as a recurring bug in the annual OWASP Top-10 surveys. Like SQLi, CSRF is a simple-but-damaging vulnerability that endures largely because of the tension in software development between security and productivity.
The following topics will be covered in this chapter:
- Mechanics of CSRF
- Tools to use for finding and validating CSRF vulnerabilities
- Discovering, validating, and reporting on CSRF vulnerabilities
