Re: Early feedback on encrypted session PR

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. On Wed, 18 May 2022 at 18:43, Christoph M. Becker <cmbecker69@gmx.de> wrote: > > On 18.05.2022 at 18:37, Craig Francis wrote: > > > On 18 May 2022, at 17:02, Mark Randall <marandall@php.net> wrote: > > > >> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >