Re: Is MM cookie auth 'secure' thru HTTP proxy servers?
Further to what I said before (see below), I now enclose a patch to correct the problem. The patch is to the WebAuthenticate function in Mailman.SecurityManager. It adopts the simple hypothesis that if you are setting or checking a cookie then the response about to be made shouldn't be cached.
Date: Mon, 22 Apr 2002 17:30:14 +0100 To: mailman-developers@python.org From: Richard Barrett <r.barrett@ftel.co.uk> Subject: Is MM cookie auth 'secure' thru HTTP proxy servers?
Can someone out there sanity check my thinking on a possible hole in Mailman's cookie based authentication.
The scenario I'm concerned with is when Mailman's web GUI is being accessed by a browser via a caching HTTP proxy server such as Squid, hardly an uncommon situation these days.
If my understanding is correct, then Squid (legitimately and like probably any other HTTP proxy) has no qualms about caching a page merely because of the existence of Cookies or Set-Cookie headers in the response or request. This is justified by RFC 2616. The Squid FAQ says:
<quote> The presence of Cookies headers in requests does not affect whether or not an HTTP reply can be cached. Similarly, the presence of Set-Cookie headers in replies does not affect whether the reply can be cached. </quote>
It appears to me that in the absence of a Cache-Control header with a value of private, no-cache or no-store a caching proxy server is free to cache the response to an HTTP request purportedly protected by MM's cookie based authentication AND to again serve that response to any other requesting client WITHOUT consulting the server delivering the Mailman web GUI.
I am hoping one of you kind readers will tell me I have missed the obvious in my examination of the problem and the MM source, or that the scenario above is invalid for any reason.
In the meantime I'm working up a patch to block this possible security hole by adding Cache-Control headers in the HHTP responses generated by MM's web GUI.
patch file: cut here -------------------------------------------------------------------------- --- mailman-2.0.10/Mailman/SecurityManager.py Tue Nov 6 04:25:26 2001 +++ mailman-2.0.10-cache/Mailman/SecurityManager.py Tue Apr 23 09:44:22 2002 @@ -31,7 +31,7 @@ from Mailman import Cookie from Mailman import mm_cfg - +nocache = "Cache-Control: private" class SecurityManager: def InitVars(self, crypted_password): @@ -66,10 +66,14 @@ self.ConfirmUserPassword(user, password) else: self.ConfirmAdminPassword(password) + print nocache print self.MakeCookie(key) return 1 else: - return self.CheckCookie(key) + res = self.CheckCookie(key) + if res: + print nocache + return res def MakeCookie(self, key): # Ingredients for our cookie: our `secret' which is the list's admin cut here --------------------------------------------------------------------------
"RB" == Richard Barrett <R.Barrett@ftel.co.uk> writes:
RB> Further to what I said before (see below), I now enclose a
RB> patch to correct the problem. The patch is to the
RB> WebAuthenticate function in Mailman.SecurityManager. It adopts
RB> the simple hypothesis that if you are setting or checking a
RB> cookie then the response about to be made shouldn't be cached.
Thanks Richard.
I don't think the patch is quite right but it's close. I can't produce a diff right now (I'm replying to this while off-line) but I'll generate patches against MM2.0.10 and MM2.1cvs when I get a chance.
What do folks think, does this warrant a 2.0.11 release?
-Barry
participants (2)
-
barry@zope.com
-
Richard Barrett