Earlier, I briefly mentioned that browsers will pass along all associated cookies to applications automatically. For example, if the user has authenticated to the http://email.site application, a session cookie will be created, which can be used to make authenticated requests. A CSRF attack takes advantage of this user experience feature to abuse overly-trusting applications.

It is common for applications to allow users to update their profile with custom values that are passed via GET or POST requests. The application will, of course, check to see whether the request is authenticated and perhaps even sanitize the input to prevent SQLi or XSS attacks.

Consider a scenario where we've tricked the victim into visiting a malicious site, or perhaps we've embedded some JavaScript code in a known-good site. This particular piece of code is designed to perform a CSRF attack and target the http://email.site application.

As attackers, we've done some digging and realized that the email application provides a way to update the password recovery email through the profile page: http://email.site/profile/.

When we submit a change on our own test account, we notice the following URL being called:

http://email.site/profile/[email protected]

If we're able to modify another user's password recovery email, we can reset their credentials and potentially login as that user. This is where a CSRF attack comes into play. While the application does validate the email address value and the request must be authenticated, there are no other security checks.

A CSRF attack embeds an invisible iframe, img, or similar element in a malicious site, which makes a cross-origin request to the target application using attacker-supplied values. When the victim's browser attempts to load the iframe or img element, it will also pass the session cookies along with the request. From the application's point of view, this is a valid request and it is allowed to execute. Attackers may not be able to read the response, since it is made cross-origin (remember SOP?) but the damage has already been done.

In our malicious site, we embed an img tag with the source pointing to the profile update URL containing our email address as the new value.

A typical CSRF attack flows something like the following:

Figure 9.7: CSRF attack flow

When the user visits our malicious site, the image will attempt to load by making an authenticated GET request to the target application, updating the recovery email for the victim on the email application. We now have the ability to request a password reset for the victim's account and login to the email site directly.

To prevent CSRF attacks, developers should implement CSRF tokens. These are unique, one-time numbers (nonces) generated for every request to a protected page. When a request to update any part of the application is made, the client must send this unique value, along with the request, before the data is allowed to change. Theoretically, attackers embedding img tags in their own malicious site would have no way of guessing this particular token, therefore CSRF attacks would fail.

CSRF tokens are a good defense against CSRF, if implemented properly. First of all, the value should be unique, non-deterministic, and hard to guess. A small random integer does not make a good token because it can easily be brute-forced. An MD5 hash of the username or any other static guessable value is not good enough either.

CSRF tokens should be tied to the user session and if that session is destroyed, the tokens should go with it. If tokens are global, attackers can generate them on their own accounts and use them to target others.

CSRF tokens should also be time-limited. After a reasonable amount of time, the token should expire and should never come up again. If tokens are passed via GET requests, they might be cached by proxies or the browser, and attackers can simply harvest old values and reuse them.

When we encounter CSRF tokens in a target application, we should check for issues with the implementation. You'd be surprised how many times the CSRF token is issued but ignored when passed back to the server.

CSRF is an interesting vulnerability that can often be chained together with other issues, such as XSS, to perform an effective attack against a particular target.

Say we had discovered a stored XSS vulnerability in the profile page of the email application. We could update our name to reflect some XSS payload. Since we cannot affect other users' profile names, this XSS payload would only really trigger for our account. This is referred to as self-XSS. If the same application is also vulnerable to CSRF attacks on both the login and logout pages, we could force a user to logout and also force them to login as somebody else.

First of all, we would submit an XSS payload into our own profile name and save it for later. Then, we could build a malicious site that performs the following operations in order:

The malicious code would look something like this:

Figure 9.8: Malicious self-XSS and CSRF attack code

The http://email.site/profile/ contains the self-XSS code we stored earlier, which would execute on the unsuspecting target once the iframe loads.

What can we do with JavaScript code running in the victim's browser, but under our account session? It doesn't make sense to steal session cookies, but we have other options, as we will see next.