Early feedback on encrypted session PR

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:*eric@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/

Thanks all for the early feedback.

So it is an attempt to mitigate tampering attacks basically on session
stored on filesystems. So it appears to be a subset of session usage
overall indeed but
doing so in a native manner is what drove the PR.

Personally I usually just throw the session key through a one-way hash so the original session ID never gets written to a backing store.

Good idea, but that's not done by default.

But also not by the PR, as I understand it.

I'm not sure why reversible encryption needs to take place?

It might provide privacy (if the attacker can read the session files, and they contain sensitive information, e.g. some developers store a copy of the users entire record in the session to avoid db lookups)... and it might prevent edits being made to the session file.

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.

I would hope both are very rare, but I'm still writing up reports about developers doing things like file_put_contents('/tmp/' . $_POST['id'], $_POST['message']), so I don't have a lot of hope.

Right. And no amount of magic features implemented by a language or
library will prevent such issues completely. It might not have been the
best idea to make PHP so beginner friendly.

--
Christoph M. Becker

--

To unsubscribe, visit: https://www.php.net/unsub.php

I would hope both are very rare, but I'm still writing up reports about developers doing things like file_put_contents('/tmp/' . $_POST['id'], $_POST['message']), so I don't have a lot of hope.

Right. And no amount of magic features implemented by a language or library will prevent such issues completely. It might not have been the best idea to make PHP so beginner friendly.

True, but some features can catch or help limit the damage from some mistakes (e.g. CSP), as mistakes can be made by any developer (no one writes 100% secure code); and magic_quotes was not on that list.

Also, while I appreciate your sentiment (I feel it all too often), overall I prefer having loads of beginners that are learning and guided by the language/tooling, so they eventually become experienced developers for a popular language :-)

Craig