[OWASP-GUIDE] White paper: Authentication and Session Management on the Web
paul at westpoint.ltd.uk
Thu Feb 10 05:15:46 EST 2005
>To me, the referrer is a defense-in-depth control. The new version of the
>Guide recommends against relying upon it, but it can be a useful control for
>the 99+% of casual attackers who just try out your app using a browser
>Granted it will never stop any of us (or any tooled-up or Perl capable
>attacker), but for the low entry cost, referrer checks are worthwhile along
>with other controls, if only for the delay factor.
You misunderstand my intentions in using the referer. For the person
generating the request, it is trivially spoofable. Ok, it may require
coding or an interactive proxy, but I still consider that trivial.
HOWEVER, the attacker will not always be the one generating the request.
For CSRF, the attacker causes the victim's browser to make a request
(generally by getting the victim to click a link). The attacker just
does not have control of the referer header in this situation. And the
attacker can't generate the request themselves, because they don't have
the session cookie, which they're relying on the victim's browser to
attach for them.
Before CSRF there was another reason for doing this. Hot linking - i.e.
opening a free web space account, linking to the images from another
site. This makes the free host handle some of your bandwidth, without
you ever showing their adverts. Referer checking can be used to prevent
hot linking. The hostile web operator has no control of how his user's
browsers send the referer header. If the free web host blocks image
accesses which have an off-site referer, they block hot linking for the
vast majority of users. The hostile web operator cannot tolerate this
and so they stop hot linking. Here we have a definite security gain,
based solely on the spoofable referer headers.
However, CSRF and hot linking are not quite the same problem. For hot
linking, it suffices to block the majority of users. However, we can't
catch them all, because some don't send the referer header and others
send one like "referer blocked". I don't think it's acceptable to expose
those users to CSRF, and in any case there is a better solution using
auth tokens in hidden form fields. So, ultimately, referer is probably
not the best way to stop CSRF.
Someone suggested the other day an interesting way to use the referer
header to harden web apps:
1) Block all POST requests with an off-site referer (unless there's
a specific need)
2) Filter query string from all GET requests with an off-site referer
Not thought about it much, but it seems quite sensible.
>>A safeguard that I didn't see you mention is the use of a unique token in
>>each form, passed as a hidden form element. Because a CSRF attack attempts
>>to forge a request from someone else (the victim), checking for this
>>unique token forces an attacker to capture the one associated with the
>>victim and the form being spoofed.
>[Andrew van der Stock]
>For .NET applications, could a token hidden in the MAC obfuscated ViewState
>be considered adequate?
>I'm not a huge fan of secondary tokens as they go against the simplicity
>argument. In general my clients are rarely capable of writing
>cryptographically robust session management schemes, for which secondary
>tokens fall into.
>Also, Paul has gratefully allowed me to summarize his paper's techniques
>into the Guide. Look for that this weekend when I release 2.0 a4. Also, I've
>received Frank Lemmon's corrections, and I've added much more besides. It's
>starting to look more like it's finished. :)
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>Owasp-guide mailing list
>Owasp-guide at lists.sourceforge.net
Paul Johnston, GSEC
Internet Security Specialist
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul at westpoint.ltd.uk
More information about the Owasp-guide