WebApp Sec mailing list archives
Re: Session ID Abuse
From: Steve Shah <sshah () planetoid org>
Date: Sun, 15 Feb 2004 11:47:11 -0800
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...
Current thread:
- Session ID Abuse Johnny GoLightly (Feb 13)
- Re: Session ID Abuse Paul (Feb 15)
- Re: Session ID Abuse lists AT dawes DOT za DOT net (Feb 15)
- <Possible follow-ups>
- session id abuse Johnny GoLightly (Feb 13)
- Re: session id abuse npguy (Feb 15)
- Re: session id abuse hans (Feb 15)
- RE: Session ID Abuse Kris Wilkinson (Feb 15)
- Re: Session ID Abuse Steve Shah (Feb 15)