On Fri, Sep 3, 2010 at 4:02 PM, Luke Plant <l.plant...@cantab.net> wrote: > 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.
I agree; cookies are poorly specified and have issues. I don't see the relevance to this though. > > 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". 10 years ago we just called it a variant of XSS. > > 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. That's just word juggling, "We must interoperate with an implementation that does not provide Referer headers", and we don't - if you fail the CSRF test, it isn't some functionality you lose, it's all (for that request, at least). The reliance on Referer specifically stops us from interopating with implementations that do not provide it. Sending Referer headers is a UA decision, and can be controlled quite easily by the end user, system admin or proxy admin. Relying on it's existence allows for unpredictable behaviour, and allows the decisions made by some sys admin to deny our clients access to our sites, which never looks good. I don't want ever to have to explain that FooGlobal clients couldn't log in because their sysadmin doesn't like Referer headers, and our chosen framework can't handle that. > > 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. > Are you sure? 13.5 discusses how transparent caches may reconstruct responses from what they have cached; the section you have quoted from 13.5.2 is talking about the issues that may arise with proxies that modify/remove headers, so I don't think it readily applies in this scenario. Also, unless I've very much missed something, there have been no later versions of HTTP. > 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 > I'm not sure, it needs more thought. As I understand it, the requirement for strict referer checking came about as a result of a regression to the earlier implementation, brought about by no longer tieing the nonce to the user's session. One avenue to look at would be to reverting that decision, and finding alternate solutions to the problems it is trying to solve, that doesn't involve breaking support for compliant UAs. There's no rush on my part; I'd like to see this fixed before 1.3, but the number of users it impacts is small, and actually protecting against CSRF is more important. I'll have a think this weekend.. Cheers Tom -- 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.
