Re: improvements in session management?

[dd <dd () ghettohackers net>]

While including additional information is nice, be careful that you 
don't also pick information that may not stay the same during a valid 
session.  For instance, REMOTE_ADDR can change due to a load balanced 
proxy setup.

There are several methods for making it very hard to use a stolen 
sessionid cookie.  This could include checking things like user agent, 
acceptable languages, but better by adding data that changes on each 
request via cookie, form field, etc (call this the SINGLEUSEID).  In 
addition, make sure a user can only be part of a single valid session. 
One could also invalidate a session if an unexpected SINGLEUSEID is seen.

Usually, if you are willing to use this method of securing a sessionid 
token the user is also coming in over SSL.  The SSL key/cert in use 
shouldn't change and therefor there is a perfect opportunity to include 
some information (keyid, certid, etc) into the session for additional 
verification.

This of course still leaves the user open to browser hijacking via a XSS.

dd

Mark Foster wrote:
> WebAppSecurity [Technicalinfo.net] wrote:
>
> > I don't see the necessity for storing the user_agent for session 
> > handling -
> > unless you need it to decide on which client-side code components you 
> > will
> > introduce as part of a dynamic application.  Like any field submitted in
> > HTTP(S) headers, it can be defined by the client and overwritten as
> > necessary - so HTTP_USER_AGENT is most certainly not a unique field 
> > that can
> > be trusted.
>
>
> Regarding the sessionID in most cases it seems to be a token that grants 
> the holder access to the session variables and state on the server 
> application. So it needs to be kept "secret" to avoid session hijacking.
> My goal was/is to keep the "secrets" close to home. I see no reason to 
> give the session id to the browser as a cookie or URL parameter, when 
> the shifts the burden of trust to the user. The sessionID becomes the 
> password in a sense. I just want to UNIQUELY identify the end-user via a 
> browser cookie, then correlate that on the server side to an active 
> session. So even if some joker figures out the users unique cookie, it 
> is not enough to hijack anything, since the session is accessible only 
> to someone who knows the unique cookie AND knows the specific USER_AGENT 
> and is at the REMOTE_ADDR. By combining elements of authentication this 
> is a way to achieve better security, right?