[ZCM] [ZC] 364/ 2 Reject "Cookie Authentication Secutiry Hole"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #364 Update (Reject) "Cookie Authentication Secutiry Hole"
 ** Security Related ** (Public)
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/364

==============================================================
= Reject - Entry #2 by ShaneH on May 2, 2003 9:51 am

 Status: Pending => Rejected

This is a problem with CMF / CookieCrumbler, not Zope.  Please file the bug in the CMF collector.
________________________________________
= Request - Entry #1 by Anonymous User on Apr 23, 2002 9:35 am

Someone out there might like to sanity check my thinking on a possible security hole that arises if some form of cookie authentication, the CookieCrumbler for instance, is used with Zope.

The scenario of concern is when cookie authentication is being used and Zope is accessed by a browser via a caching HTTP proxy server such as Squid, hardly an uncommon situation these days. I believe that transparent proxy servers are quite extensively used at the internet access points of ISPs.

As 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 if the Zope server fails to add a Cache-Control header with a value of private, no-cache or no-store to its responses, a caching proxy server is free to cache the response to an HTTP request. Hence the proxy server can again serve the response, purportedly protected by cookie based authentication, to any other requesting client WITHOUT consulting the Zope server.

I could not identify any code in the CookieCrumbler to add a Cache-Control header with a value of private, no-cache or no-store to Zope responses.

This problem should not occur when Zope uses the regular Basic Authentication scheme as per RFC2616:

<quote>
Note that section 14.8 normally prevents a shared cache from saving and returning a response to a previous request if that request included an Authorization header.
</quote>

Unless someone can refute this scenario (please, please do) then it appears to me that Cache-Control headers need to be added to all responses conditional on authentication by Zope using cookie authentication.

Maybe Zope should just add a Cache-Control header with a value of private, no-cache or no-store to all responses that its security sub-system determines are to other than the Anonymous user. It would do no harm if Basic Authentication were being used and would plug the security hole I have posited if cookie authentication were in use.

I'd propose a patch myself but I am not that confident in hacking around Zope's security management code.

==============================================================