[eluser]WanWizard[/eluser]
To maintain session state, there are a few things that need to happen.
You need server side storage, that should be secure, only accessable by your application, and accessed via a random session id. Managing all this is the task of the session library.
And you need a link between the user('s http client) and the session storage of that users client. To do that, the random session id needs to be send to the client, so the client can send it back with the next request to identify itself.
There are several options to send this session id back:
* via a cookie mechanism. This is the most secure, since it allows you to add additional security mechanisms that you can validate before using the session id stored in the cookie.
- - obviously this requires a cookie-enabled client
* via a URL GET parameter.
- - If you only pass the session_id (like PHP does with its PHP_SESSID), it is very insecure. Anyone getting hold of that value can hijack your session
- - you could create an array, add extra fields to it, serialize it, encrypt it, and use that as identifier. Chances are it's going to be to big for the URL
* via a POST variable
- - same mechanism as via GET, but not visible to the user. Requires every request to the server to be an HTTP POST though, which is inpractical.
Now storing any data client side is a security best practice. Anything that leaves the server can be captured, analyzed, broken and used. If it not leaves the server, that hacking route is out the window.
There are (in the case of cookies) also pratical issues: a cookie can have a maximum of 4Kb of payload, and you can only have 20 cookies per domain (a few more with recent browsers).
The issue with PHP session storage is that by default they are stored in a central location on the server, and the webserver needs r/w access to them. Which means any script that runs with that webserver's credentials can access the session files, even if they are from other applicatios running on that same host. Now there are ways to make this more secure, but in my experience there are not a lot of hosting companies, and virtually no dedicated server owners, that deploy these measures.
If you also use PHP's session mechanism for the state (so real PHP native sessions), a cookie or GET variable called PHP_SESSID is used (by default), which contains the full unencrypted and unsecured session id. Getting this cookie or appending it to a URL is enough to hijack someone else's session. And trust me, stealing a cookie is quite a simple task.
Hence my statement that using PHP's sessions is not a good idea.
If you don't like storing session data in the database (there are valid reasons not to want that), use a file-based (or mongodb, memcached, redis, ...) driver instead and deploy the same security measures for the session cookie as used in the session library.