the-web-application-hackers-handbook

506 Chapter 13 n Attacking Users: Other Techniques
Exploiting CSRF Flaws
CSRF vulnerabilities arise primarily in cases where applications rely solely on
HTTP cookies for tracking sessions. Once an application has set a cookie in a
user’s browser, the browser automatically submits that cookie to the application
in every subsequent request. This is true regardless of whether the request originates
from a link, form within the application itself, or from any other source
such as an external website or a link clicked in an e-mail. If the application does
not take precautions against an attacker’s “riding” on its users’ sessions in this
way, it is vulnerable to CSRF.
HACK STEPS
1. Review the key functionality within the application, as identified in your
application mapping exercises (see Chapter 4).
2. Find an application function that can be used to perform some sensitive
action on behalf of an unwitting user, that relies solely on cookies
for tracking user sessions, and that employs request parameters that an
attacker can fully determine in advance—that is, that do not contain any
other tokens or unpredictable items.
3. Create an HTML page that issues the desired request without any user
interaction. For GET requests, you can place an tag with the src
attribute set to the vulnerable URL. For POST requests, you can create a
form that contains hidden fields for all the relevant parameters required
for the attack and that has its target set to the vulnerable URL. You can
use JavaScript to autosubmit the form as soon as the page loads.
4. While logged in to the application, use the same browser to load your
crafted HTML page. Verify that the desired action is carried out within the
application.
TIP The possibility of CSRF attacks alters the impact of numerous other
categories of vulnerability by introducing an additional vector for their exploitation.
For example, consider an administrative function that takes a user
identifier in a parameter and displays information about the specified user.
The function is subject to rigorous access control, but it contains a SQL injection
vulnerability in the uid parameter. Since application administrators are
trusted and have full control of the database in any case, the SQL injection
vulnerability might be considered low risk. However, because the function
does not (as originally intended) perform any administrative action, it is not
protected against CSRF. From an attacker’s perspective, the function is just as