Hi Tom,
On Thu, 2010-09-02 at 11:34 +0100, Tom Evans wrote:
> Any sort of Referer checking is broken by design, since that header is
> clearly optional. RFC 2616 makes explicitly clear that applications
> should not rely on Referer being sent. Any argument that sending it
> "is virtually never a privacy concern" is moot; you must not rely on
> the existence of that header, even if it is a useful tool in 99% of
> cases.
Thanks for your input. I've got 3 main responses:
1) Lots of things are "broken by design" on the internet. The fact that
HTTPS and HTTP cookies are not completely segregated from each other in
browsers is one example we've mentioned recently - it is completely
brain dead, and punches a huge hole in the security of many HTTPS
applications.
In fact, it is difficult to determine exactly whether it is "by design"
or not since there is essentially no spec for cookies. In theory, we
should be using RFC 2109, but no-one else is really doing that - they
are using something half way between 'Netscape' cookies and RFC 2109.
Actually, we all ought to be using RFC 2965, which advocates Set-Cookie2
which fixes and obsoletes 2109, but virtually no-one is doing that
either.
Anyway, RFC 2616 was written 10 years ago, when no-one had even heard of
CSRF. Allowing a Man-in-the-middle to go ahead and make a CSRF attack on
an HTTPS connection is, technically speaking, RFC compliant. But that
would be far more "broken by design".
2) If you are going for a RFC based approach, you need to be more
careful about the use of "SHOULD NOT" and "MUST NOT", and "OPTIONAL" -
see RFC 2119, which says that we MUST interoperate with an
implementation which does not provide an OPTIONAL item, "though perhaps
with reduced functionality". I can't find anywhere that says that we
MUST NOT rely on an OPTIONAL header for some of our functionality.
In fact, a note in section 13.5.2 or RFC 2616 says:
Warning: unnecessary modification of end-to-end headers might
cause authentication failures if stronger authentication
mechanisms are introduced in later versions of HTTP. Such
authentication mechanisms MAY rely on the values of header fields
not listed here.
Which I think gives us explicit permission to do what we are doing.
3) What alternative do you propose, given the real world security
problem that the HTTPS Referer check solves and the constraints that we
are working under?
Thanks,
Luke
--
A mosquito cried out in pain:
"A chemist has poisoned my brain!"
The cause of his sorrow
was para-dichloro-
diphenyltrichloroethane
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
