[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webappsec
Subject:    Re: Session ID Abuse
From:       Steve Shah <sshah () planetoid ! org>
Date:       2004-02-15 19:47:11
Message-ID: 20040215194711.GA45941 () marvin ! planetoid ! org
[Download RAW message or body]

On Fri, Feb 13, 2004 at 08:47:14AM -0700, Kris Wilkinson wrote:
> 2.  Knowing the session id (perhaps from info on the URL) can one create
> another session from another browser using the same session ID?
> 
> Never store your session id anywhere that a user can find easily.

Answering the original question, yes. HTTP is stateless meaning that
when you see the session ID again, you have no way of accurately
knowing whether the client has changed browsers, machines, etc.

> 3.  How can you effectively limit concurrent access to only 1 session?
> 
> When the user logs in, grab his IP address and store this value in an
> adjacent table column. Ie ... When the user is authenticated to access
> the page verify the IP address against the session id in your database.
> Its only a small solution to your problem, but it's a step in the right
> direction.

This will break in many circumstances. Users behind NATs will not be
able to use the application at the same time and users behind load
balanced forward proxies will lose persistence. e.g., a single AOL
user may pop out of multiple client IP addresses during the lifetime
of a session. A user behind a firewall that has multiple NAT IP
addresses may also appear from multiple client IP addresses during
the same session. The only accurate piece of information that you
have to identify a user is their session ID.

> 4.  If client side certificates were to be used, could you create
> another session from another browser once the first session was
> authenticated?  ie, how do you restrict the access to only one browser?

Yes. The only difference between the two is going to be the symmetric
key that was negotiated at SSL session setup. I don't know of any
web server that passes this information up to the application and
even if it did, I would avoid using it. The day your application sits
behind an SSL accelerator, you'll be in trouble. Any suggestions to
use the SSL session ID are also incorrect as this value may change
during a single user session if the cached session ID either time outs
or one of the sides decides to renegotiate from click to click. 

> 6.  If a user with high privileges (such as write to db) leaves a
> workstation unattended with no session timeout, are there any controls
> that one could put in place to still validate the user is the privilged
> user after a period of time?  for example keep session active, but to
> make any changes application must validate information on a usb key? 
> 
> It takes 2 seconds for a user to login again ... just force them to
> enter their username and password.

This is an excellent idea. One akin to sudo-like functionality for a
web application.

> 7.  How do you choose between session ID's tagged in URL, and Session
> IDs in cookies?  How do you restrict the information in either URL or
> cookie so that users can't use this info to abuse the application?

Use only one of them, cookies usually being the better choice since
URLs tend to be cut and pasted around. Expire the cookie is part 1.
Embed time information in your session ID is another. Make sure that
you're securing your cookie with some cryptographic means so that
the cookie cannot be altered by the client.


-- 
Steve Shah
sshah@planetoid.org - http://www.planetoid.org/
Beating code into submission, one OS at a time...
[prev in list] [next in list] [prev in thread] [next in thread]