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.
Thanks!
Floyd
On Jul 22, 2009, at 9:36 AM, Andrew Ballard wrote:
On Wed, Jul 22, 2009 at 8:36 AM, Ashley
Sheridan<ash@xxxxxxxxxxxxxxxxxxxx> wrote:
But *how* does it offer more security? You've not actually mentioned
that!
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.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
