[Zope] CoreSessionTracking: Brute-Forcing Web Application Session IDs

[Chris McDonough]

It's probably useful to walk through a real-world example...

You develop an application using sessions that is a typical "shopping
cart" sort of app, where the cart items are kept in a session data
object, and the user needn't be authenticated (in any other way than
having a session id) to place items in his cart.  At checkout, he
needs to jump through a couple of hoops to actually buy the items.

Let's say for sake of example that the session ids are one character
long.  Obviously, they'd be very guessable.  So let's say a bad guy
comes along and plays around long enough to figure out the sessioning
weakness, and he subsequently guesses a couple session ids.  He goes
into each session he can guess and messes around with the cart items,
adding some items to one person's cart, removing some other items from
another person's cart, etc.

This is annoying, of course, but it's not too bad yet.  The bad guy
can't actually *buy* anything as another person.  For that level of
access, you'd want to make sure that the user provides a validation; a
username-password combo or a credit card number.  You'd want to
explicitly make sure that he couldn't a) get the person's address,
phone number or (god forbid) credit card number as a result of getting
a session id by sniffing it or guessing it.

The article that Frank sent over deals with apps that are built around
session ids as sort of a psuedo authentication credential.  We're
going to recommend in Zope 2.5 sessioning docs that you don't do that.
Sensitive information should be protected in ways other than just with
a session id.

So given that we deem that it's bad design to keep sensitive info
around in sessions like credit card numbers, phone numbers, addresses,
etc, and given that session ids are even now currently pretty tough to
casually guess (19 characters, 8 of which are randomly generated), are
there mitigatable risks which have a solution that doesn't depend on
unchanging IP addresses that I'm overlooking?

- C


----- Original Message -----
From: "Joachim Werner" <joe@iuveno-net.de>
To: "Chris McDonough" <chrism@zope.com>; <zope@zope.org>; "Frank
Tegtmeyer" <fte@lightwerk.com>
Sent: Monday, November 26, 2001 8:49 PM
Subject: Re: [Zope] CoreSessionTracking: Brute-Forcing Web Application
Session IDs


> > Also, I actually think it's a more effective defense to not rely
on a
> > session id to protect data.  There was lots of discussion about
this
> > when CST was in its infancy, and the decision was to recommend
that
> > folks not use sessioning to try to protect sensitive data.  The
> > shared-key encryption of a sessionid if IP addresses are not used
in
> > the hash seem like only a step above pig latin.  Instead if you
need
> > to do something sensitive, use a username/password combination.
> >
> > Does this seem reasonable?
>
> Hi!
>
> You are right that sessions might not be the rigth thing to protect
really
> secure stuff, like Extranet access, but I would not want to have
anonymous
> users of a shopping cart application log in with a username and
password.
> These shopping cart applications are where you need both ease of use
(which
> can only be provided by a session) and (at least some) protection.
So it is
> a GOOD THING (TM) to have session ids that are relatively hard to
guess.
> Combined with SSL that seems to be a reasonable thing to do.
>
> Joachim
>
>
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )
>