[OWASP-GUIDE] OWASP Guide 2.0a4 available
chris at shiflett.org
Tue Feb 15 19:31:05 EST 2005
--- Andrew van der Stock wrote:
> thanks for your feedback. :) It hasn't been discussed as it's new
No problem. :-) I will try to provide more as I have a chance to read it
> I wish to include referer as it is a simple control which can remove
> attackers who do not have tools. As I've mentioned before on the list,
> pretty much any tool will get around this control. However, as a
> defense in depth control, it is easy to implement and is worth
> considering if only to prevent basic attacks.
I completely agree with the idea of implementing any safeguard that can
help. I'm a firm believer in defense in depth. :-)
My main concern with this suggestion is the potential adverse affect it
can have on legitimate users. I think the number of users who use
third-party software or HTTP proxies that strip or modify Referer is
This brings us back to a similar discussion we have had here before. I
think many agreed that this might be solvable if the application keeps up
with each user agent's behavior:
1. The Referer is absent.
2. The Referer is present (and consistent) but not a URL.
3. The Referer is present (and consistent) but not the expected URL.
4. The Referer is the expected URL.
(We hypothesized that no user agents fall into the third category.)
So, if a Referer check occurs after the user agent's behavior has been
recorded, the majority who fall into the fourth category can reap whatever
benefits are provided by this extra check. Those who fall into the other
categories can still use the application (and some minor checks are still
possible for the first and second categories, such as checking for
Perhaps we can slightly ammend the recommendation? (Assuming my above
logic is not flawed.)
More information about the Owasp-guide