[OWASP-GUIDE] White paper: Authentication and Session Management on the Web

Chris Shiflett chris at shiflett.org
Fri Feb 11 01:46:49 EST 2005


--- Paul Johnston <paul at westpoint.ltd.uk> wrote:
> 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.

Yes, exactly. Well said.

I do think it's good to make allocations for those legitimate users who
send a consistent Referer (e.g., it is being stripped or modified). For
the majority, whose browsers send a proper Referer, we can check to be
sure it's the URL of the form that should have been used to generate the
request (considering it to be forged otherwise). For the others, we can
still check Referer, but only for consistency. Hopefully that makes some
sense - it's late. :-)

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

Yes, I very much like that approach, with the caveat I mentioned above.
I'm thinking that when a Referer is stripped or modified that it is never
changed to a valid URL, so this approach might be fine under the
circumstances that the Referer is a valid but external URL. Anyone have a
more authoritative answer?

Chris




More information about the Owasp-guide mailing list