Cross-site request forgery

Overview[1]#

Cross-site request forgery (CSRF or XSRF or CXRF) is a type of exploit in HTTP where unauthorized commands are transmitted from a user-agent that the website trusts.

Cross-site request forgery "tricks" a victim's browser into sending a HTTP Request to a vulnerable Website, which then performs an undesired action on behalf of the victim (for example, changing credentials, making an illegal purchase, or performing online financial operation).

Cross-site request forgery exploit is extremely widespread since the majority of today's Website rely solely on automatically submitted credentials such as session cookies, basic Authentication Scheme credentials, source IP addresses, Secure Socket Layer (SSL) certificates, or Microsoft Windows domain credentials. Therefore, as the user is currently authenticated to the site, the site will have no way to distinguish a Cross-site request forgery attack from a legitimate user request.

Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, Cross-site request forgery exploits the trust that a website has in a user-agent.

Best Practices For Automated CSRF Defense[2]#

Standard Header Checks#

Almost all requests include one or both of: Although it is trivial to "spoof" any HTTP Header Field from your own browser, it is generally impossible to do so in a Cross-site request forgery Spoofing Attack, except via an XSS vulnerability. That's why checking HTTP Header Fields is a reasonable first step in your Cross-site request forgery defense, but since they aren't always present, it is generally not considered a sufficient defense on its own.

Checking The Origin Header#

If the Origin header is present, verify its value matches the site's origin. The Origin HTTP Header Field standard was introduced as a method of defending against CSRF and other cross-domain attacks. Unlike the referrer, the origin header will be present in HTTP requests that originate from an HTTPS URL. If the origin header is present, then it should be checked to make sure it matches your site's origin.

This defense technique is specifically proposed in section 5.0 of Robust Defenses for Cross-site request forgery. This paper proposes the creation of the Origin header and its use as a CSRF defense mechanism.

Checking The Referer Header#

If the Origin header is not present, verify the hostname in the Referer HTTP Header Field matches the site's origin. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce or server-side state doesn't exist. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

In both cases, just make sure your origin check is strong. For example, if your site is "site.com" make sure "site.com.attacker.com" doesn't pass your origin check (i.e., match through the trailing / after the origin to make sure you are matching against the entire origin).

What to do when Both Origin and Referer Aren't Present#

If neither of these headers is present, which should be VERY rare, you can either accept or block the request. We recommend blocking, particularly if you aren't using a random CSRF token as your second check. You might want to log when this happens for a while and if you basically never see it, start blocking such requests.

CSRF Token#

A CSRF Token is probably a better defense.

Same-site Cookies#

Same-site Cookies defines a "SameSite" cookie attribute which allows servers to assert that a cookie ought not to be sent along with cross-site requests.

More Information#

There might be more information for this subject on one of the following:
Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!