23

Is it possible to prevent CSRF by checking the Origin and Referer headers? Is this adequate, provided that requests with neither are blocked?

Demi
  • 799
  • 1
  • 4
  • 11
  • [Same question](https://stackoverflow.com/questions/1413930/is-checking-the-referrer-enough-to-protect-against-a-csrf-attack) on Stackoverflow – Mehdi Dehghani Dec 23 '19 at 07:49

4 Answers4

26

Expanding on the answers of @Sjoerd and @lindon.

Origin vs Referer vs CSRF token

Most likely, the reason OWASP recommends also using a CSRF token, is that at the time when this recommendation was made - a significant portion of browsers did not yet support the Origin header. This is no longer the case, but people are chimpanzees.

In order to preserve privacy, any browser request can decide to omit the Referer header. So it is probably best to only check the Origin header. (In case you want to allow for users to preserve their privacy)

The Origin header is null in some cases. Note that all of these requests are GET requests, which means they should not have any side effects.

As long as you make sure the malicious website sending the requests with your browser cannot read the responses, you should be fine. This can be ensured using proper CORS headers. (Do not use Access-Control-Allow-Origin: *!)

To prevent "click-jacking", set the header X-Frame-Options: DENY. This will tell your browser that it is not allowed to display any part of your website in an iframe.

The "new" approach

Setting Cookie properties SameSite=lax or SameSite=strict will prevent CSRF attacks. This is a quite new feature though, and cannot be used alone, simply for the reason that not all common browsers support it yet. You can track support HERE.

When the browsers do, people will likely still recommend checking Origin/Referer/CSRF tokens. If they do - without giving a good reason, it is likely because they are chimps.

Tobias Bergkvist
  • 496
  • 4
  • 7
  • 2
    according to [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin#Browser_compatibility), Edge doesn't send the `Origin` header with `POST` requests – Razor Mar 24 '19 at 17:42
  • 1
    @Razor: That is a very good point! Edge 16-18 does support the SameSite cookie property. Those using Edge 12-15 (0.13% globally at the time of this comment) would be vulnerable to CSRF attacks for websites not using tokens. – Tobias Bergkvist Mar 25 '19 at 18:56
  • It also appears that this is an opt-in feature in Firefox, and is available only since version 59. [Source.](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin#Browser_compatibility) However, this is addressable by just disallowing Origin-less requests altogether, and using JavaScript for form submission. Not optimal, but good enough. – Alec Mev Oct 24 '19 at 13:38
  • 1
    Beware that Origin header is not always sent for requests on the same origin. – Alireza Jun 13 '20 at 11:05
  • @TobiasBergkvist A bit of respect for chimpanzees, please. `SameSite` is only meant as a defense-in-depth measure precisely because it doesn't prevent all types of _cross-origin_ abuse: https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/ – jub0bs Mar 27 '21 at 12:19
  • GET requests can leak data which is just as damaging as request causing a modification. For example, if a website stores your information as an image. And evil.com makes has `` then origin headers wont be sent, depending on browser/samesite policy cookies thus session might be sent. – Muhammad Umer Jun 09 '21 at 14:16
  • 1
    Consider also an attack where the request is actually sent from the same site, by user-generated content. Not technically "cross-site" request forgery I guess, but still request forgery that CSRF tokens can protect against (since you can't create a crafted URL), I think. – nog642 Jun 30 '21 at 04:56
  • 1
    @MuhammadUmer, the image will be displayed, but Same Origin Policy will prevent javascripts from reading the image contents. Only the image width and height will be available. – eel ghEEz Mar 26 '22 at 04:06
  • 1
    SameSite with lax cannot protect against all csrf attacks. https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-02#section-5.3.7.1 From the link: 1. "Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request" 2. "Features like "" [prerendering] can be exploited to create "same-site" requests without the risk of user detection." – jacob Jun 23 '22 at 18:11
11

Yes, this is secure.

However, the referer header is not exactly mandatory, so there may be browsers or proxies than don't send a referer header. This would mean that these clients can't access your web site.

With the introduction of referrer policy it is possible to remove the referer header from a forged request. So to protect against CSRF it is necessary to block any requests that are missing a referer (and origin) header.

Edit: This paper has some numbers on what portion of clients omit a referer header.

Sjoerd
  • 28,897
  • 12
  • 76
  • 102
  • What about referer header and HTTPS? If site is hosted on HTTP and CSRF is initiated from HTTPS site, there will be no referer header to check. – Marko Vodopija Apr 25 '17 at 09:34
  • If site is hosted on HTTP then you are insecure be definition. – Demi Apr 27 '17 at 16:11
  • 2
    I think one could construct a case where even a non-zero Referer should not be trusted: If the target site T contains a link to some external site X (or embeds a resource like an image from this site, e.g. an avatar) and an attacker can make modifications to site X then the request from site T to site X (containing a Referer from T) could be answered with a HTTP redirect back to site T but with some malicious action in the URL. In this case T sees a request with a Referer of T and trusts it, even though the target URL at T is controlled by X. – Steffen Ullrich Oct 23 '17 at 12:43
  • 1
    @SteffenUllrich That is an excellent point! Of course, GET requests should be idempotent so that it doesn't matter if they're "forged" because they don't change any state, but people mess that one up all the time (including expecting POST requests but allowing GETs to that endpoint as well). – CBHacking Nov 08 '18 at 20:37
  • Why checking `Origin``header alone is not enough? And also, by checking these headers, do you mean validating that the requests `Origin` header matches the ones you whitelisted in the application? – eddyP23 Nov 12 '18 at 11:11
2

The accepted answer covered most of the things already. However, there is special case where you still need CSRF token even if you SameSite=strict is enable.

For example, website A lets users post contents and embed image source from wherever they want. Then, malicious user can insert an image with src=website-a.com/remove/something. This image is shown in website A, therefore, when normal users browse to this image, request initiated from this image is same origin with website A.

One problem is, request initiated from image a GET request, most action APIs are POST. However, Malicious user can often convert request from POST to GET and server still accept it, which makes CSRF attack possible.

trieulieuf9
  • 51
  • 5
  • In this case do you need a CSRF token or do you need to ensure that GET requests don't change state? Seems like either would suffice and that the latter might be preferable, especially since [frameworks like ASP.NET Core don't validate the antiforgery token by default on GET requests](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.autovalidateantiforgerytokenattribute?view=aspnetcore-7.0#definition). – ChaseMedallion Mar 04 '23 at 11:52
0

OWASP recommends checking a CSRF token in addition to checking the origin and referer.

lindon
  • 165
  • 1
  • 7
  • 15
    I don't consider this an answer since the question was not if further things are recommended but if Referer and Origin are enough. If you feel that these are not enough please explain why instead of linking to a resource which does not explain this either. The only reason CSRF tokens are recommended additionally in the document your reference are *"to really make sure"* without further explanation. – Steffen Ullrich Apr 25 '17 at 04:37