I'm not sure I'm a fan of the PR as it stands, but the idea of
encrypting session data - definitely.
When sessions are stored on disk, that data is plainly visible by anyone
(or any process) with read access to that disk. If they're cached
instead in a DB or an in-memory system like Memcached, the same rules
apply - anyone else who can read data from that system can read what's
stored in the session. That being said, how much you care about this
level of access depends very much on your threat model. If sessions are
storing data like upvotes or view counts, this information likely isn't
sensitive enough to worry about whether or not things are encrypted.
If you're storing customer PII in a session, though, then protecting
this data "at rest" in your session store becomes critical.
It is already possible to write an own SessionHandler which
encrypts/decrypts the session payload. That said, I'm not against
adding an encryption option.
This is 100% the route I've taken in the past.
https://github.com/ericmann/sessionz (which I admit needs some updates)
includes one example SessionHandler implementation that does just that.
However, it would be fantastic to see this as part of the standard
library. Session management in PHP can be tricky, particularly in larger
applications with multiple entry/return points. A standard (read:
simplified) implementation would go a long way.
--
Security Principles for PHP Applications
<https://www.phparch.com/books/security-principles-for-php-applications/>
*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA <https://keybase.io/eamann>
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com <https://eamann.com>
ttmm.io <https://ttmm.io>
Twitter icon <https://twitter.com/ericmann> LinkedIn icon
<https://www.linkedin.com/in/ericallenmann/>
