Hello,

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

1. http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2012-January/008170.html

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:

Hi Jim,

Really?  Never come across that myself.  At least in that (rare?)
situation, the app just breaks.

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:

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.

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:

1. www.example.com/profile.jsp [original]
2. www.example.com/arbitrary_page.jsp
3. [no referrer]
4. 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:

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.

5. www.example.com.attacker.com/

--
Jason Calvert

On 03/02/2012 06:30 PM, super evr wrote:

Also check for:

5. 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:

--
...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