On 18.05.2022 at 18:37, Craig Francis wrote:
> On 18 May 2022, at 17:02, Mark Randall <marand...@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
