I wonder if I can tap the deep knowledge of this site. Consider a site that attempts to defend against CSRF by checking the Referer header.

1. If the site uses only SSL, are there any ways to bypass the Referer check? Can a Referer header be forged in a CSRF attack if all links are over HTTPS? (I know that a malicious client can send any headers it wants, but I'm talking about a CSRF attack scenario: the victim is using an ordinary browser to access a malicious website, which wants to trick the browser into visiting the target website using a forged Referer header.)

2. If user is using a recent browser, are there any ways to bypass the Referer check? I know that older versions of Flash allow spoofing Referer headers, but I'm not familiar with the current state of Referer header spoofing. Given the population of browsers out there today, are there exploits to spoof the Referer header? If not, how old a browser or how old a plugin would the user have to be using, to be vulnerable to CSRF attacks that spoof the Referer header? How many users use browsers/plugins that are that old?

Thanks for the information!

By the way, I'm not talking about ways to block the Referer header (I know there are ways to prevent transmission of the Referer header, but if no Referer header is present, this site does not allow access to the site). I'm only curious about whether there are ways to transmit a false Referer header -- is this site secure? Is checking the Referer header secure enough, if you can assume either that all users use recent browsers or that the entire site uses HTTPS?

are you talking about this?
https://addons.mozilla.org/en-US/firefox/addon/966

that allows you to change the referer that the browser sends?
or what you can set in curl
curl_setopt($s,CURLOPT_REFERER,"http://google.com");

just trying to clarify

http://www.xssed.com/archive/author=PaPPy/

I think it's about getting other people to load good.com with 'good.com' in the referer.

It all depends on how it handles the check. If it runs strpos($referer,'good.com'), you can try putting it in the query string of the csrf-ing file:
hxxp://evil.com/tryToCsrf.php?hxxp://www.good.com/

Thanks for your responses, everyone!

PaPPy, sorry that my question wasn't clear. A quick clarification: I'm not asking whether a malicious user can send a request with a forged Referer: header; of course a malicious user can include anything in their headers that they want, as they control the client. That's not the question.

In Question 1, I'm asking whether malicious site www.evil.com can mount a CSRF attack against www.good.com, if www.good.com checks that all requests include a Referer: header that refers to some URL on www.good.com, and if we also assume that www.good.com uses only HTTPS (i.e., does not serve anything via unencrypted HTTP). That's Question 1. In other words, is checking the Referer header a reliable defense against CSRF, if you use only HTTPS?

Question 2 is a variant, where now www.good.com might serve some content via HTTP, but we assume that the client's browser is fairly recent and up-to-date. I don't know exactly what I mean by recent and up-to-date, so perhaps I should frame Question 2 differently. What's the most recent browser version/plugin version such that www.evil.com can initiate a CSRF attack on www.good.com and arrange to forge the Referer header so it includes good.com in the Referer? And, how widely used is that browser/plugin? (what is its market share? what fraction of users will be susceptible?) That's Question 2. In other words, is checking the Referer header a reliable defense against CSRF, if you somehow know that all your users will be using relatively modern browsers?

PaPPy: Recall that in a CSRF attack, the user visits some site www.evil.com. Evil.com is malicious, and wants to attack the user. The user is not malicious; the user is victimized by this attack. Evil.com is trying to fool good.com into thinking that the user wanted good.com to take some action, when the user did not actually authorize or intend for that to happen.

Barbarianbob: Clever -- I like it. That would be a good attack to check for. Thanks for the idea. But let's assume that the site parses the Referer header correctly, and checks for its own domain name in the hostname portion of the URL, so your attack will not work. Are there any other attacks, assuming www.good.com codes up the Referer check properly?

does the site have an open redirect, or xss?

http://www.xssed.com/archive/author=PaPPy/

Good questions. I don't know. The site that triggered this question is www.launchpad.net, but the question also interests me in the general case (is this a reliable defense to CSRF?).

I assume that any XSS bugs discovered will get fixed, whereas the Referer checks are by design. I don't know if it has an open redirect; as many sites do, so that's plausible. Certainly an open redirect could be used to defeat Referer checks -- good point, thanks. The system also has bug reports that anyone can submit, and those bug reports can contain links (and the URLs do not seem to be filtered in any way that I'm able to identify).

well initial look i dont see any XSS on it

http://www.xssed.com/archive/author=PaPPy/

Most sites don't check the referrer, do you think that one does?

if you're asking whether it is a good idea to implement this as a protection against CSRF: I wouldn't rely on it. One time tokens are a better solution.