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

[Chris McDonough]

Here's what I have so far in the Zope Book regarding session security.=20
Expansions?:

    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.

      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.

      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.


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 site
> > 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 applications
> > until recently: you only had to send a mail to someone with in it a lin=
k
> > 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 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 the
> referrer issue, I would not have thought of it.
>=20
> - C
>=20
>=20
>=20
> _______________________________________________
> Zope-Coders mailing list
> Zope-Coders@zope.org
> http://lists.zope.org/mailman/listinfo/zope-coders