Reputation: 691
I have a database in which I store session ID's once they have been validated to a user.
From a security standpoint, should I be checking the session ID against the session ID stored in the database for every protected page being accessed?
If I do not do this, wouldn't it be possible for someone to hijack the validated session ID, and do a post with the necessary variables to access restricted pages?
From a performance standpoint - if I should be checking the session ID against the database for every request, would it be significantly more efficient to store validated session ID's in their own text files instead of making so many database queries?
Thanks in advance.
Upvotes: 1
Views: 5027
Reputation: 16846
About security:
You describe the hijack risk yourself quite well. More important is the question of how likely this would happen and how sensitive your site / data is.
Now if someone takes over the pc of a registered user who didn't destroy the session (log off), how would you determine this? And why / how should the session ID change and still be valid?
It would probably be better to check the identity of the caller by accessing a cookie, checking the ip (on ip change re-logon), ...
About performance:
In general a text file query should take much longer than a database query, since the text file is almost always a file system / storage query, while the database query will often be in memory (cached).
Think of your database as another software program running in the background - it's basically instantly accessible if it runs on the same server.
-> Correct me if I'm wrong...
Upvotes: 2
Reputation: 1350
Yes, you should check the session ID on every request. It's still possible for session hijacking to occur, although a rolling session ID would help mitigate this (i.e. change the session ID on each request).
It would not be more efficient to validate session IDs in a text file versus a database if your RDBMS supports results caching (MySQL calls this query caching).
If your query just verifies the existence of a session id like SELECT COUNT(session_id) FROM sessions WHERE session_id = ?
(you are using parametrised queries to prevent SQL injection, right?) then this may be cached (although MySQL may not do so in versions earlier than 5.1.17).
If/when there is no cache, the lookup should not cause any issues. Switching to an in-memory table at that point may be a good idea.
Upvotes: 3
Reputation: 14938
Generaly speaking checking and regenerating ID session occurs when you change status of user. IE : user X get the admin access : You must check is session id before grant access and you regenerate a new id after the operation.
Upvotes: 0
Reputation: 6209
From a security standpoint, should I be checking the session ID against the session ID stored in the database for every protected page being accessed?
If I do not do this, wouldn't it be possible for someone to hijack the validated session ID, and do a post with the necessary variables to access restricted pages?
Yes, and you'll probably want to include some additional information in your database - e.g. last time accessed, ip address.
Upvotes: 1