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 )