Re: unique session id

Incremental generation of ids is not very secure, because a user could easily hijack someone else's session just by bumping his/her session id up or down.

I've also seen security problems with random session ids, though. For example, the WebX message board system, a popular commercial BBS. It uses some very funky session IDs to track logins. However, it also allows limited HTML, including hyperlinks. So, all I need to do is add a hyperlink into my message that leads to a CGI script on a server I control. The CGI script reads the HTTP_REFERER info, and forwards it to me via email. Now I have that user's session ID, and if I get there before their session times out, I can hijack their session and forge messages, mess with configuration settings, etc.

Just things to consider when you are going to be using session IDs.

Comment on Re: unique session id

Replies are listed 'Best First'.
RE: Re: unique session id by DrManhattan (Chaplain) on Jun 08, 2000 at 22:39 UTC
That's a good point. Just generating a random session id isn't enough. You also have to make sure you aren't getting a session id from a client other than the one you issued it to. There was a really interesting thread about securing session ids on the mod_perl mailing list a couple of months ago. The trick is that you need to store some validation information such as the client's ip address or a session timeout along with the session key. That way you can verify (or at least be more certain) that the client presenting the session key to you is the correct one. There are basically two schools of thought: You can either encrypt the extra information in the session key itself, or you can store in it a database indexed by the session key. Each method has its advatanges. The first requires some processing overhead to decrypt the data stored in the session key and possibly more bandwidth since the session keys may be longer. The second requires a database hit each time you verify the key. It's essentially a CPU vs. IO tradeoff. Here's a link to the thread: http://forum.swarthmore.edu/epigone/modperl/jytwortwor/20000420121516.B31518@eziba.com - Matt	[reply]

Replies are listed 'Best First'.

RE: Re: unique session id
by DrManhattan (Chaplain) on Jun 08, 2000 at 22:39 UTC

There was a really interesting thread about securing session ids on the mod_perl mailing list a couple of months ago.

The trick is that you need to store some validation information such as the client's ip address or a session timeout along with the session key. That way you can verify (or at least be more certain) that the client presenting the session key to you is the correct one.

There are basically two schools of thought: You can either encrypt the extra information in the session key itself, or you can store in it a database indexed by the session key. Each method has its advatanges. The first requires some processing overhead to decrypt the data stored in the session key and possibly more bandwidth since the session keys may be longer. The second requires a database hit each time you verify the key. It's essentially a CPU vs. IO tradeoff.

Here's a link to the thread: http://forum.swarthmore.edu/epigone/modperl/jytwortwor/20000420121516.B31518@eziba.com

[reply]