Cross-site Request Forgery - Limitations

Limitations

Several things have to happen for cross-site request forgery to succeed:

1. The attacker must target either a site that doesn't check the referrer header (which is common) or a victim with a browser or plugin bug that allows referer spoofing (which is rare).
2. The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password).
3. The attacker must determine the right values for all the form's or URL's inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will fail.
4. The attacker must lure the victim to a Web page with malicious code while the victim is logged in to the target site.

Note that the attack is blind; i.e., the attacker can't see what the target website sends back to the victim in response to the forged requests, unless he exploits a cross-site scripting or other bug at the target website. Similarly, the attacker can only target any links or submit any forms that come up after the initial forged request if those subsequent links or forms are similarly predictable. (Multiple targets can be simulated by including multiple images on a page, or by using JavaScript to introduce a delay between clicks.)

Given these constraints, an attacker might have difficulty finding logged-in victims or attackable form submissions. On the other hand, attack attempts are easy to mount and invisible to victims, and application designers are less familiar with and prepared for CSRF attacks than they are for, say, password-guessing dictionary attacks.