Floyd Resler wrote:
The nice thing about the database, though, is that you can specify which MySQL user has access to the sessions table. That way you can really lock it down by giving access to only INSERT, SELECT, UPDATE, and DELETE just for that table.


On Jul 22, 2009, at 9:36 AM, Andrew Ballard wrote:

On Wed, Jul 22, 2009 at 8:36 AM, Ashley
Sheridan<a...@ashleysheridan.co.uk> wrote:
But *how* does it offer more security? You've not actually mentioned

One way would be to encapsulate data access in stored procedures and
deny direct table access on the session data. That way, even though
the PHP account has access to the database where all sessions are
stored, it can only call a ReadSession procedure that requires the
session_id() as a parameter. That way, PHP would have to know the ID
of the session and could not simply SELECT * FROM sessions.

However, I haven't found many examples that use stored procedures.
Most just use regular INSERT/SELECT/UPDATE/DELETE statements, which
means that the PHP user has full access to the entire table. In that
case, it's no more trivial to scan the session table than it is to
scan the session save path looking for interesting stuff.

A custom session handler that writes to files could easily encrypt session data so that only the user with the correct session ID can decrypt it. I think you're confusing the issue by claiming database sessions are more secure when what you really mean is that custom sessions are more secure than the default session system.

Application and Templating Framework for PHP

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to