Title: Dangers of using the Referer Header for CSRF checks Category: Web Application Security Date: 2017-05-10
Cross Site Request Forgery is a common type of web application vulnerability that can easily be mitigated by doing the following:
- Checking the HTTP Referer header
- Using CSRF tokens
- Ensuring that the website does not contain any Cross Site Scripting vulnerabilities
Unfortunately I have noticed that many applications only use the 1st "HTTP Referer header" check, resulting in an interesting dilemma for developers: How to handle requests with no HTTP Referer header?
Many applications will not enforce CSRF checks on requests that do not contain a HTTP Referer header. One example of such an application is pfSense. I reported this issue to the developers in August 2016, and they could not release a patch. This is because there are many legitimate cases where a request does not contain a Referer header. For example:
- Entering URLs manually into the browser
- Following bookmarks
- Following saved links in e-mails or other locations
This makes it possible for attackers to bypass CSRF checks, for example, by entice a user to click on a link embedded in a PDF or Word file. This results in a request with no Referer header.
Although unlikely to be used, this entire attack vector can be mitigated by using CSRF tokens.