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.
"RB" == Richard Barrett R.Barrett@ftel.co.uk writes:
RB> Can someone out there sanity check my thinking on a possible
RB> hole in Mailman's cookie based authentication.
RB> The scenario I'm concerned with is when Mailman's web GUI is
RB> being accessed by a browser via a caching HTTP proxy server
RB> such as Squid, hardly an uncommon situation these days.
RB> If my understanding is correct, then Squid (legitimately and
RB> like probably any other HTTP proxy) has no qualms about
RB> caching a page merely because of the existence of Cookies or
RB> Set-Cookie headers in the response or request. This is
RB> justified by RFC 2616. The Squid FAQ says:
Now that I'm back online, I doubled checked the RFC. Section 9.5 POST says:
Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.
I think we're safe and probably don't need to change anything. All Mailman interactions are done through POSTs, except for public archiver hits, and those /can/ be cached.
So unless I'm off-base, I think we're fine as-is. -Barry
participants (2)
-
barry@zope.com
-
Richard Barrett