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

[Chris McDonough]

Thanks, I've changed it.

On Wed, 2002-08-21 at 10:56, Florent Guillaume wrote:
> I'd rewrite the end as:
>=20
> 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.
>=20
> 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.
>=20
> 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
> Florent
>=20
> 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 s=
ite
> > > > 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 =
the
> > > > case of anonymous users you're doomed.
> > >=20
> > > Right.
> > >=20
> > > > This kind of bug was prevalent in a huge number of webmail applicat=
ions
> > > > 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 ful=
l
> > > > 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 =
the
> > > new edition of the Zope Book
> > > http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Sessions.=
stx
> > > .  It needs to be expanded and modified... thanks for pointing out th=
e
> > > 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
>=20
>=20
> _______________________________________________
> Zope-Coders mailing list
> Zope-Coders@zope.org
> http://lists.zope.org/mailman/listinfo/zope-coders