[Zope-CMF] Re: [Plone-developers] PLIP - Ship SessionCrumbler instead of CookieCrumbler

[Jean-Marc Orliaguet]

Simon Eisenmann wrote:

>Hi,
>
>i just added a PLIP to start a discussion about getting rid of
>CookieCrumbler in default Plone.
>
>http://plone.org/development/plips/plip.2004-10-11.4698490525
>
>Thoughts?
>
>  
>
Hi!

>Best regards,
> Simon
>
>
>  
>
I have tried SessionCrumbler:

Problem #1: performance drops

Problem #2: is it really more secure?
I suppose that it is going to be marketed as a "more secure 
CookieCrumbler" for Plone.
Fine, except that it is not. It opens a new series of possible attacks 
while giving the user a feeling of security. The only thing an attacker 
needs to get a hold on is the Zope ID, and some applications will have 
to be adapted to not expose it in the URL.

---------------------------------------------
see: http://www.plope.com/Books/2_7Edition/Sessions.stx#2-36

Sessions - Security Considerations

Sessions are insecure by their very nature. If an attacker gets a hold 
of someone's browser id, and if they can construct a cookie or use form 
elements or URL elements to pose as that user from their own browser, 
they will have access to all information in that user's session. 
Sessions are not a replacement for authentication for this reason.

Ideally, you'd like to make certain that nobody but the user its 
intended for gets a hold of his browser id. To take steps in this 
direction, and if you're truly concerned about security, you will ensure 
that you use cookies to maintain browser id information, and you will 
secure the link between your users and your site using SSL. In this 
configuration, it is more difficult to "steal" browser id information as 
the browser id will not be evident in the URL and it will be very 
difficult for attackers to "tap" the encrypted link between the browser 
and the Zope site.

There are significant additional risks to user privacy in employing 
sessions in your application, especially if you use URL-based or 
formvar-based browser ids. Commonly, a browser id is embedded into a 
form/querystring or a URL in order to service users who don't have 
cookies turned on.

For example, this kind of bug was present until recently in a lot of 
webmail applications: if you sent a mail to someone that included a link 
to a site whose logs you could read, and the user clicked on the link in 
his webmail page, the full URL of the page, including the authentication 
(stored as session information in the URL) would be sent as a HTTP 
REFERER to your site.

Nowadays all serious webmail applications either choose to store at 
least some of the authentication information outside of the URL (in a 
cookie for instance), or process all the user-originated URLs included 
in the mail to make them go through a redirection that sanitizes the 
HTTP REFERER.

The moral of the story is: if you're going to use sessions to store 
sensitive information, and you link to external sites within your own 
site, you're best off using /only/ cookie-based browser ids.
---------------------------------------------

Problem #3: ZEO
The data is not shared between ZEO instances.
The suggestion is to mount the session folder on ZEO. Fine but then you 
are transmitting the password between the zope and the ZEO server 
unencrypted.
It is a hack on top of a hack on top of a hack..

Solution: #1:
I wrote a RAMCacheCrumbler that stores all sensitive information in 
protected areas in RAM or in a protected object in the session.
references: http://mail.zope.org/pipermail/zope-cmf/2004-October/021343.html
It is fast but it is a hack on top of a hack.

Solution: #2:
Get rid of the CookieCrumbler and fix the user folder(s). (this already 
works with PluggableUserFolder for instance, cf the 
KerberosIdentification and the CAS plugins)
It is no longer a hack, the password is never stored, but it has to be 
done for every user folder.

Solution: #3:
M.-A Darche from Nuxeo wrote in 
http://lists.nuxeo.com/pipermail/cps-devel/2004-October/001132.html that 
Unilog has developed a crumbler that does not store the password and 
works with ZEO and that is going to be integrated in CPS. I am 
interested in knowing how they did.

All in all, I would suggest that the hardcoded references to 
CookieCrumbler in Plone be removed, that is a good start.

PS: I CC: to cps-devel and zope-cmf  because this is where the 
discussion started and the issues that you are raising are not 
Plone-specific.

Regards /JM