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

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 site has in a user-agent.

General Recommendations For Automated CSRF Defense[2]#

Standard Header Checks#

Almost all requests include one or both of:
  • Origin Header
  • Referer Header
Although it is trivial to spoof any header from your own browser, it is generally impossible to do so in a CSRF attack, except via an XSS vulnerability. That's why checking headers is a reasonable first step in your Cross-site request forgery defense, but since they aren't always present, its 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 the best defense.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-8) was last changed on 28-Jul-2017 10:10 by jim