Five Ways to Reduce Your Vulnerability to CSRF Attacks - Page 2
What can a CSRF attack achieve?
Although a CSRF attack can "only" carry out a transaction in a Web application, the results can be very far-ranging indeed. For example, it could result in the victim unwittingly making a forum posting, subscribing to a mailing list, making purchases or stock trades, or carrying out activities such as changing a user name or password. CSRF attacks work on applications protected behind the same firewall that the victim is located, and can allow a hacker to access an application which has access restricted by IP range if the victim's machine is within that range.
A strange twist on CSRF is called login CSRF, which logs a victim into a Web application using the attacker's credentials. This allows the hacker to log in subsequently and retrieve information about the victim, such as the user's activity history, or any confidential information that has been submitted by the victim.
How to mitigate the risk of your Web applications being vulnerable to CSRF attacks
- Limit the time-to-expiration of authentication cookies. The shorter the period in which these cookies are valid, the smaller the window of opportunity for a hacker to exploit your Web application. However, the shorter the period the more inconvenient it is for users. In the end, as is often the case, there is a compromise to be made between convenience and security.
- Make users submit additional information before allowing important transactions to be carried out. Requiring a user to solve a CAPTCHA or enter a password before important transactions can be carried out can prevent a hacker from carrying out an attack (as long as the password is not stored in the browser) because this information is not predictable (CAPTCHA) or freely available (password).
- Use secret non-predictable validation tokens. CSRF attacks work when a session is identified only by the cookie stored in the user's browser. So they can be foiled by having additional session-specific information in each HTTP request that a attacker can't know in advance, and therefore add to a link. If the app has an existing cross site scripting vulnerability it might still enable a hacker to access this validation token, however.
- Use custom HTTP headers. The XMLHttpRequest API can be used to protect against CSRF attacks if all requests that carry out a transaction use XMLHttpRequest and attach a custom HTTP header, rejecting any such requests which lack the custom header. This is useful because browsers normally only allow sites to send custom HTTP headers to the same site, thus preventing a transaction being initiated from the site which is the source of the CSRF attack.
- Check the referrer header. When a browser sends an HTTP request it usually includes the URL that it originated from in the referrer header. In theory you can use this information to block requests that originate from another site instead of from within the Web application itself. Unfortunately the referer header is not always present (some organizations strip it out for privacy reasons, for example) or can be spoofed, so this measure is not really effective.