Security Minded Sessions

drawmack

I wrote up a class for storing sessions in a database. The goal was to make sessions more secure. I focused on the two main session attacks, high-jacking and session fixation. While it is impossible to use sessions that cannot be high-jacked or fixated, simply because you must get the session id from the client, you can make these attacks harder to accomplish. The source code is in the attached zip file, what follows is an explaination of what I've attempted to accomplish and some of my concerns and points for reveiw.

Database Sessions with Improved Security

This class uses a database to store the sessions and implements some security precautions on retrieving/setting the session id as well. A database is used, instead of flat files, in an attempt to avoid performance issues. The security precautions produce a great deal of overhead in starting a session, so optimizing information retrieval becomes paramount in keeping session performance at a maximum.

There are three security precautions enabled.

The first is a session id validation. This means that every session id passed to the system must match. For example if there are session ids passed in the query string and via a cookie, those two session ids must match or the system generates and uses a new session id. This will protect against session fixation, where the user already has a session id stored on their computer.

The second method is an existence check. If the user passes a session id to the system, then a database record should be stored with that id. If there is no database record with that id then the session is reset with a new session id.

The third precaution is a validity check. Every time a user visits a page that uses sessions their ip is recorded and a unique session token is created. The session token is stored in a cookie on the users system as well as in the database. Then the system checks to make sure that the token and the user’s ip are the registered token and ip for this session. If this check fails the session is reset with a new session id.

Whenever a session is reset with a new id an error of level E_USER_WARNING is generated. Any program using this package should trap for this error and respond accordingly, as when a session id is reset any information currently stored in the user’s session is lost.

These measures make session fixation and high-jacking much harder to accomplish.

In a session fixation attack the attacker attempts to provide the session id to the user. Then the attacker can use this session id to high-jack the user’s session. With this system when an attacker provides a session id to the user, if it is not already in the database, the user will be issued a new session id. If the id is already in the database, but they do not posses the correct ip address and session token they will be issued a new session id. This means that session fixation is all but impossible as the attacker would have to spoof their ip to the same as the target’s, create a session, give the target the session token and session id and then high-jack the session. However the token is changed every time a sessioned page is retrieved, therefore the attacker would also have to obtain the new session token before they could high-jack the session.

In a session high-jacking attack the attacker figures out a users session id and then spoofs their session id so that the system thinks they are the target. This system makes this difficult as well. The attacker would have to spoof the target’s ip and gain the current token for the target’s session. However once the attacker high-jacked the target’s session the target’s token would become invalid. Then the next time the target accessed a sessioned page their session would be reset and their session information would be deleted from the database. So while still possible to high-jack sessions it is very difficult and has a limited time frame in which it will work.

User Unfriendliness of This Solution

Most times when you implement security precautions it is done at the expense of user friendliness. This is the case with this solution. User friendliness is negatively impacted in two ways. The first is that the user’s browser must accept cookies or they will end up getting a new session id every time they access a sessioned page. The second way is that if a suspected attack is detected the user’s session is reset and they loose all the data that was in their session. If you have a shopping cart and the user has been in your store for a while this could be a substantial loss of data. However, if the user is made aware of this possibility and that if this happens it means your system successfully prevented an attack against this user, they will probably be willing to forgive you for loosing their data.

Concerns and Points for Review

Concerns:

Reliability – does the system create false positives and/or false negatives? If so how and can you suggest a fix?
Scalability – does the system work as well on large or high traffic applications as it does on small or low traffic applications? If not why and can you suggest a fix?
Compatibility – does the system work under other versions of php & mysql? If not which ones and can you suggest a fix?
Refresh Errors – if you refresh two times before the code can complete it creates a situation where, while you are a valid user your token does not match the database token. This could create problems with people using their back buttons if the site is set up for no cache. If anyone has ideas on how to fix this I would be very grateful.[/list=1]
Points for Review:
1. User Friendliness – is there solutions to the security problems that have a smaller impact on user friendliness? If so, what are they?
2. Performance – can this be made to run faster? If so, how?
3. Ease of use – how difficult (1 – 10) is it to set this up on a new and an existing site? If you have difficulties, what are they and can you suggest corrections?
4. If you are using different versions of MySQL (4.0.20) and PHP (4.3.8) then I am and this runs on your server please let me know so I can add them to the tested environments list.
  [/list=1]
  
  Thank you for taking the time to look this over for me.
  
  Edit: Added AES encryption to the data in the database

drawmack

This has generated little interest and I'm wondering why? I'd really like to use this code in an article and I'm hoping to get feedback first. Is there something I can do to make people more interested in this?

Sgarissta

My first comment just based on your description (haven't had a chance to dig into the code yet) is that IP based checking is worthless. In our environment we have a load balancer in front of all our webservers. PHP reports the IP of the loadbalancer instead of the client, this would severely mangle the way your session security is handled.

Also using some sort of DB abstraction layer (Pear:😃B or the like) would also be of a lot of benifit, as our primary environment runs Oracle for the DB server.

I'm also weary (but well aware of the reasoning) behind the use of a second cookie for the token.

As far as efficiency of the code goes I would say it's pretty efficient.

I'll think some more about it and see if I can come up with some more constructive criticism.

drawmack

Originally posted by Sgarissta
My first comment just based on your description (haven't had a chance to dig into the code yet) is that IP based checking is worthless. In our environment we have a load balancer in front of all our webservers. PHP reports the IP of the loadbalancer instead of the client, this would severely mangle the way your session security is handled.

I had contemplated problems with that, but not this one - that is a very good point. However, if every one coming in has the same IP then it would laxen the security just a tad, however the system would still work. As the ip reported would match the ip in the database.

Also using some sort of DB abstraction layer (Pear:😃B or the like) would also be of a lot of benifit, as our primary environment runs Oracle for the DB server.

But then the abstraction package needs to be seucrity validated. I konw know of any open source packages that are security validated and since this is for a tutorial I really didn't feel like going to all that trouble.

I'm also weary (but well aware of the reasoning) behind the use of a second cookie for the token.

Yeah, the only way to really check if someone is who they are valid for the session id they are passing is to have some other kind of check. I guess I could generate the token from the user's environment variable (i.e. browser, port, etc.) Though I wonder behind your load balancer how much of this information would become invalid.

I'll think some more about it and see if I can come up with some more constructive criticism.

Cool thanks.

Sgarissta

Originally posted by drawmack

But then the abstraction package needs to be seucrity validated. I konw know of any open source packages that are security validated and since this is for a tutorial I really didn't feel like going to all that trouble.

The DB abstraction layer itself (if done appropriately) would not change the security of the system in any way. As long as you follow the same conventions you would otherwise (ex: checking user submitted data) it should not create any more security concerns than are already inherent to the system.

Yeah, the only way to really check if someone is who they are valid for the session id they are passing is to have some other kind of check. I guess I could generate the token from the user's environment variable (i.e. browser, port, etc.) Though I wonder behind your load balancer how much of this information would become invalid.
[/B]

From my personal experience I would say that the solution above provides only marginally better security, to an already insecure system. The best (and most annoying in its own right) method of session security in my opinion, is not allowing get/post submitted session ids, browser session only cookies, and short expiration time for inactive sessions.

Also you mention in your original statement that file access is inherently slow (and i don't disagree) but do you have any benchmarks showing that despite the overhead of database management your method is still more efficient than file based sessions? (especially in the case of a DB server on a separate box)

If this is for an article, you might mention some of the scenarios where DB based sessions are more applicable than files. (such as a round robin DNS based "cluster" solution where a true clustered filesystem is not available)

All in all, I'd still say it looks like a very well thought out, and coded idea. Just not something that I personally (given our environment) could find a lot of use for.

drawmack

Originally posted by Sgarissta
The DB abstraction layer itself (if done appropriately) would not change the security of the system in any way. As long as you follow the same conventions you would otherwise (ex: checking user submitted data) it should not create any more security concerns than are already inherent to the system.

You're right they shouldn't but without a security validation of the code there is nothing to say that they do not.

From my personal experience I would say that the solution above provides only marginally better security, to an already insecure system. The best (and most annoying in its own right) method of session security in my opinion, is not allowing get/post submitted session ids, browser session only cookies, and short expiration time for inactive sessions.

The system does allow for that. The implementor sets the timeout and also says where valid session ids can come from (get, post, cookie). Though with the way the system is layed out you really don't need to limit that because it will check all supplied and allowed parameters where a session id can be passed from and compare them to the session id that php registered. If any of the supplied session ids do not match the one php is using (i.e. do not match each other) then the session is reset with a new session id.

Also you mention in your original statement that file access is inherently slow (and i don't disagree) but do you have any benchmarks showing that despite the overhead of database management your method is still more efficient than file based sessions? (especially in the case of a DB server on a separate box)

No, that's why I listed performance on a point for concern. Generally speaking db access is faster then file access and this is a well documented generalization. I am using that generalization in the hopes that this specific case is not wrong.

If this is for an article, you might mention some of the scenarios where DB based sessions are more applicable than files. (such as a round robin DNS based "cluster" solution where a true clustered filesystem is not available)

I was planning on that, however I personally feel that db based sessions are always better. This is from a scalability point of view. For example want to throw in a user's on line feature and have database sessions, it's about 3 lines of code. Want to split your site across two load balanced servers, try doing that with file based sessions (talk about slow).

All in all, I'd still say it looks like a very well thought out, and coded idea. Just not something that I personally (given our environment) could find a lot of use for. [/B]

It's really not intended to be a solution per se. It's more of a start on getting the bar on session security up a little higher then it is right now. It's also for an article which means it is ment to spark ideas on how you may take some of the pieces and build on them.

Just curious how much harder do you think it makes session fixation and highjacking?

jystewart

Thanks for posting this. I've been looking into ways of further securing my session code so this provides useful food for thought.

My key concern is with using IP addresses to test against session IDs is where users are sitting behind load-balanced proxies that result in a different IP address for each request from the same client.

I know various service providers (AOL?) have utilised such systems in the past but haven't checked lately to see how widely they're being used today. If they are still in broad-use it would be a major hindrance.

drawmack

Originally posted by jystewart
My key concern is with using IP addresses to test against session IDs is where users are sitting behind load-balanced proxies that result in a different IP address for each request from the same client.

I know various service providers (AOL?) have utilised such systems in the past but haven't checked lately to see how widely they're being used today. If they are still in broad-use it would be a major hindrance.

This is one of the problems I anticipated. I think that most load balancing systems today would result in every user having the same (and therefor valid) ip address. I stuck it in there anyway cause it's only one if statement to remove it from the checks.

PHPMagician

Considering the problems it may cause some people maybe it would be appropiate to have two different classes, one for the developer to use, and one that is the actual functionality.

The one open to the developer could then offer the ability to set rules: basically, to enable/disable certain features of your system. Also, maybe change between file and db based sessions. When PHP5 becomes more mainstream then SQLite would be a good thing to look into for session management in my opinion.

rehfeld

i did not look through the code too much, because i just dont have time right now.

but one thing i did noticed in the 30 seconds i looked at it, was that your hardcoding the session name. anyone who doesnt use PHPSESSID will have to modify the code alot. you can use session_name() to retrieve the current session name so the script is not so proprietary.

have a look at this, i think this guy has a fairly good idea going.

http://www.n3rds.com.ar/files/docs/php_sessions/sess_handler.txt