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.
Best Practices For Automated CSRF Defense#
Standard Header Checks#Almost all requests include one or both of:
- Origin Header
- Referer Header
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 is probably a better defense. 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:
- Authorization Server Authentication of the End-User
- Encoding claims in the OAuth 2 state parameter using a JWT
- OAuth state parameter
- Same-site Cookies
- Web Blog_blogentry_150617_1
- [#1] - Cross-site_request_forgery - based on information obtained 2016-08-08-
- [#2] - Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet - based on information obtained 2016-08-08-