Menu
Is checking the referrer enough to protect against a cross site request forgery attack? I know the referrer can be spoofed, but is there any way for the attacker to do that FOR the client? I know tokens are the norm, but would this work?
658
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.
The most effective method of protecting against CSRF is by using anti-CSRF tokens. The developer should add such tokens to all forms that allow users to perform any state-changing operations. When an operation is submitted, the web application should then check for the presence of the correct token.
Login CSRF can be mitigated by creating pre-sessions (sessions before a user is authenticated) and including tokens in login form.
In the case of GET requests, it prevents JavaScript to read the response data. This also applies in the case when page B is embedded as an <iframe> on the page A. Cross-Origin Resource Sharing (CORS) is not a CSRF prevention mechanism.
This is Expert Verified Answer The CSRF attack is also known as Cross-Site Request Forgery. It is a critical attack inadvertently causing an end user to employ web applications where they are already authenticated to allegedly perform unauthorized actions.
Using one of the following values in the SameSite attribute of a session cookie, a website can protect itself from CSRF attack. Cookies set with SameSite : strict will disable cookies being sent to all third party websites.
This is a 3 year old question with four different answers basically stating the same thing: Follow the norm, use tokens, don't try to use referer.
While tokens still is considered the most secure option, using the referer is often a lot easier, and is also pretty secure. Just be sure to look at all PUT/POST/PATCH/DELETE-requests and consider it an attack if a referer is missing or from the wrong domain. Really few (if any) proxies remove the referer for these kinds of requests.
See also the OWASP recommendation about checking the referer header as a CSRF protection:
Checking The Referer Header
Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. 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.
However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check. It should be noted that GET requests should never incur a state change as this is a violation of the HTTP specification.
There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.
116
Among other things, using the referrer won't work for users whose browsers (or corporate proxies) don't send referrers.
41
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
