Session State and Security

Session state control is a tough thing to handle. If you are in a web farm environment it gets even tougher. What are the options?

1. Use an IIS Session State server
2. Don't use web farms and use the Session object
3. Manage session state manually by passing a key

It is option number three that I want to talk about. Option 2 doesn't work if you have to build reliability into your system and Option 1 only works if you have the extra money.

Session Key Management
So, how would you do this? Most developers will generate a unique key and pass it back and forth, or maybe even use the ViewState. I like to use both.

When trying to use manual session keys, I will generate the key and then append it to all internal links plus add it to the ViewState for post-backs. This is that hard, just have an extra function that is called last iterate and append the data to all hyperlink objects (doesn't work it you use HTML href's). But is this secure?

I came up with, IMHO, a method for securing the session key itself. Stay with me, it gets interesting. First off, you will need the following data:

• Browser User Agent (ServerVariables value)
• First three octets of client IP address (Parse the ServerVariables value)
• Unique user number (Probably from a database or server side xml file)
• Last accessed timestamp

Here is how a typical first interaction will transpire with those values:

1. Upon first access, update last accessed timestamp
2. Take all four values and append into one large string
3. Use a hashing algorithm (I like SHA256) and hash the string
4. Store the returned value (now your session key) and pass to client in ViewState and appended to links

Now that we have our key, most people would stop here and just pass it back and forth, validating it against the stored value in the database.... but that isn't secure. Nope, if all you did was pass it around than ANYBODY could snatch it and use it. To be secure we need to follow a second set of steps whenever a return user accesses our site:

1. Take the passed in session key and validate it matches a current one in the database. Some developers also enforce a "session" timeout and check the last accessed time and log them out if it exceeds the system timeout. For our purposes, we will assume they have not reached system timeout.
2. Now that it is valid, we ditch the entire key and RECREATE IT AS WE DID BEFORE. Read that again... we get all four of the ORIGINAL values, append them, and hash them. Then we validate against the database to see if they still match. This is the security we are looking for.
   
3. Now that we are positive the keys match, we ditch the entire key again, update the last accessed timestamp, and create a new key and deliver it to the client the same way we did with the initial key.

Interesting? I have found that it stops all of the session abuse I have witnessed in the past. Anybody see a vulnerability with this scheme? Thoughts?