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 <cmbecke...@gmx.de> wrote:
>
> 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
