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

Chris Shiflett chris at shiflett.org
Fri Feb 11 01:31:07 EST 2005

--- Andrew van der Stock <vanderaj at greebo.net> wrote:
> 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 alone.

I agree. I tend to recommend that Referer not be used for anything, and if
someone challenges me on that and demonstrates a good understanding of
things, I'll mention where I think it can be useful (for defense in depth,
exactly as you suggest). I'm just very careful not to encourage the
misconceptions, because I think they're dangerous.

I'll admit that this might not be the best approach to take in terms of
education, but it's the direction I've chosen. I think most people's use
of Referer is a red herring.

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

Just to be clear (I'll try to follow up by locating this in the guide),
the recommendation is to check for consistency, right? Checking for the
expected URL can have adverse affects for a legitimate user, especially
with some of the software and proxies that strip or modify Referer:

Referer: Blocked by RefBlock (http://refblock.com/)

(I made that up, but hopefully it's clear.)

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

Perhaps we have different implementations of this idea. My mention of a
token was only in regard to the CSRF discussion. If all "important" forms
(e.g., those that perform some action, as described in RFC 2616) include a
unique token in a hidden form field, then a successful CSRF attack becomes
much more difficult. In fact, I'm not sure of a better safeguard, although
I'd be very happy for someone to provide me with one. :-)

> Also, Paul has gratefully allowed me to summarize his paper's
> techniques into the Guide.


By the way, I'd be more than happy to help out with the guide,
particularly concerning any PHP-specific documentation. I'm also
interested in any cross-pollination between OWASP and the PHP Security
Consortium. There is a public guide currently available here:


We hope to refine and improve it significantly over the course of the next
few months.

> It's starting to look more like it's finished. :)

Sounds good. :-) Thanks for all the work you put into this.


More information about the Owasp-guide mailing list