PHP Session Validation - Best Practices

Question

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.

Even if a session was hijacked, how would validating the session ID detect/prevent the session hijacking? — Gumbo
– Gumbo, Commented Feb 10, 2011 at 16:17
The purpose of the database is to store other variables related to the activity of each specific session. — nicktendo
– nicktendo, Commented Feb 10, 2011 at 16:27
@user589294: Why don’t you store them right in the session? — Gumbo
– Gumbo, Commented Feb 10, 2011 at 16:35

Alan Pearce · Accepted Answer · 2011-02-10 16:20:43Z

3

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.

answered Feb 10, 2011 at 16:20

Alan Pearce

1,35010 silver badges18 bronze badges

Sign up to request clarification or add additional context in comments.

2 Comments

nicktendo Over a year ago

Would generating and storing a new session ID upon every request become a performance issue?

Alan Pearce Over a year ago

@user589294: Not likely, the functions usually used for generating hashes for session IDs can easily run thousands of times per second, have a look at luka8088's comment on php.net/manual/en/function.hash.php, although it's a good idea to hash multiple times, but perhaps not so many as for a password.

Martin Hennings · Accepted Answer · 2011-02-10 16:23:03Z

2

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...

edited Feb 10, 2011 at 16:23

answered Feb 10, 2011 at 16:13

Martin Hennings

17k9 gold badges51 silver badges70 bronze badges

2 Comments

nicktendo Over a year ago

Is it typical protocol for session validation methods to include IP validation per session ID? Could this potentially create any compatibility issues for a user?

Martin Hennings Over a year ago

I would not say "typical" but still considerable as an option. Again it depends on the sensitivity of your data. One (quite insensitve) site I maintain has a restricted area where I only check for the cookie and the time of last visit (this prevents stealing via 'back' button).

jwir3 · Accepted Answer · 2011-02-10 16:18:06Z

1

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.

answered Feb 10, 2011 at 16:18

jwir3

6,2195 gold badges51 silver badges99 bronze badges

Comments

grunk · Accepted Answer · 2011-02-10 16:20:18Z

0

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.

answered Feb 10, 2011 at 16:20

grunk

15k16 gold badges69 silver badges111 bronze badges

2 Comments

nicktendo Over a year ago

So you are suggesting that it is unnecessary to check the session ID of the client upon every request made to a restricted page?

grunk Over a year ago

exactly, my suggestion is a good for performance and protect the user session on each critical action.

Collectives™ on Stack Overflow

PHP Session Validation - Best Practices

4 Answers 4

2 Comments

2 Comments

Comments

2 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

4 Answers 4

2 Comments

2 Comments

Comments

2 Comments

Your Answer

Sign up or log in

Post as a guest

Related