[Zope-Coders] Re: [Zope-Checkins] CVS: Zope/lib/python/Products/Sessions/stresstests - stresstestMultiThread.py:1.5

[Florent Guillaume]

I'd rewrite the end as:

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

Florent

On Wed, 2002-08-21 at 16:36, Chris McDonough wrote:
> Here's what I have so far in the Zope Book regarding session security.=20
> Expansions?:
>=20
>     Security Considerations
>=20
>       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.
>=20
>       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.
>=20
>       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.
>=20
>       The problem is that now any an external site that's linked from
>       a site using form-based or URL-based session information may
>       receive your users' session information in the HTTP REFERER
>       information.  Operators of these sites may cull their logs and
>       connect to your system with another user's browser id, thus
>       gaining access to the information stored in their session.
>=20
>       This kind of bug was prevalent in a huge number of webmail
>       applications until recently: you only had to send a mail to
>       someone with in it a link to a site whose logs you could read,
>       and voil=E0, you had their full authentication (because they
>       stored session information in the URL).  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.
>=20
>=20
> On Wed, 2002-08-21 at 10:14, Chris McDonough wrote:
> > > The problem is that now any an external site that's linked from a sit=
e
> > > using this feature will receive as a Referer all your session
> > > information. I know that sessions aren't supposed to be used for
> > > authentication, but I'm not sure everyone will comply, and also in th=
e
> > > case of anonymous users you're doomed.
> >=20
> > Right.
> >=20
> > > This kind of bug was prevalent in a huge number of webmail applicatio=
ns
> > > until recently: you only had to send a mail to someone with in it a l=
ink
> > > to a site whose logs you could read, and voil=E0, you had their full
> > > authentication (because they were stored as session in the URL).
> >=20
> > Right.
> >=20
> > I'm hoping that the reward outweighs the risk...=20
> >=20
> > There is an obligatory security warning in the sessioning chapter of th=
e
> > new edition of the Zope Book
> > http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Sessions.st=
x
> > .  It needs to be expanded and modified... thanks for pointing out the
> > referrer issue, I would not have thought of it.
> >=20
> > - C
=20
--=20
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com