Comment 8 for bug 560246

I argued earlier that checking the Referer header is not an effective defense against CSRF, but I suspect my argument was not specific or concrete enough to be convincing. Let me try again, this time with more technical specifics:

Query: Are the Launchpad maintainers sure they know about all the attacks against the Referer header? Before answering, you may wish to read Section IV.C of this paper: http://www.cs.berkeley.edu/~devdatta/papers/websec-csf10.pdf

In particular, the attack described in that paper goes something like this:
1. Suppose the attacker owns and controls the server attacker.com.
2. The attacker posts a link https://attacker.com/badstuff on a launchpad page.
3. The victim (who is a launchpad user and is logged on to launchpad) visits that launchpad page and clicks on the link to https://attacker.com/badstuff.
4. The victim's browser requests https://attacker.com/badstuff from the attacker's server, and sends Referer: https://launchpad.net/foo in the headers.
5. The attacker's server responds with a 301 Redirect, which redirects the victim's browser to https://bugs.launchpad.net/csrfurl
6. The victim's browser receives the redirect, requests https://bugs.launchpad.net/csrfurl from the launchpad server, and sends Referer: https://launchpad.net/foo with the request.
7. The launchpad server sees a Referer header that appears valid and therefore processes the request for /csrfurl by performing some side-effecting action, under the (mistaken) assumption that the user must have requested that action.

The key observation in the attack is that browsers copy the Referer header sent in the original request across redirects. In other words, when a user at site A clicks a link to site B, and site B issues a redirect to site C, the browser sends Referer: A to site C.

This is just one of numerous attacks against Referer-checking. There have been others in the past as well (e.g., Flash-based attacks), some of which may still be pertinent today, and I fully expect other attacks may well exist, too, even if we are not aware of them. Therefore, adding some ad-hoc defense against redirects is not, in my view, right solution. Rather, I think the takeaway lesson is this: Referer headers are not an effective or reliable defense against CSRF attacks. Referer headers were not designed for this purpose. There are subtle ways to manipulate them; browser behavior can be surprising and have unexpected consequences for security mechanisms that rely upon the validity of Referer headers. It is for this reason that security experts universally (in my experience) recommend against using Referer-checking to prevent CSRF. Therefore, Launchpad's decision to rely upon Referer headers seems like one that should perhaps be revisited.

I have not attempted to mount a redirect-based attack, such as the one sketched above, against Launchpad, so I have not confirmed whether Launchpad is vulnerable. However, it appears to me that Launchpad may be creating a false tradeoff between security and usability. If my analysis is correct, it sounds like Launchpad may have chosen a solution that achieves neither security nor usability. There are better ways to defend against CSRF that are both secure and do not sacrifice usability (for the small fraction of users who block Referer headers). If defense against CSRF is important, it's not clear that the current mechanism is sufficient to meet the security goals, and perhaps Launchpad should adopt some other mechanism (e.g., one of the standard accepted approaches, which by the way do not block users who use Referer-blocking). If defense against CSRF is not important, than perhaps the current mechanism should be eliminated entirely.