[Mailman-Developers] Re: Is MM cookie auth 'secure' thru HTTP proxy servers?

Richard Barrett R.Barrett@ftel.co.uk
Tue, 23 Apr 2002 11:03:19 +0100


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