Re: [PHP-DEV] Early feedback on encrypted session PR

[Craig Francis]

On 18 May 2022, at 18:43, Christoph M. Becker  wrote:
> On 18.05.2022 at 18:37, Craig Francis wrote:
>> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Early feedback on encrypted session PR

[David CARLIER]

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

Re: [PHP-DEV] Early feedback on encrypted session PR

[Eric Mann via internals]

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 


*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 

Re: [PHP-DEV] Early feedback on encrypted session PR

[Christoph M. Becker]

On 18.05.2022 at 18:37, Craig Francis wrote:

> On 18 May 2022, at 17:02, Mark Randall  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

Re: [PHP-DEV] Early feedback on encrypted session PR

[Craig Francis]

On 18 May 2022, at 17:02, Mark Randall  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.


> 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.

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.

Craig

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Early feedback on encrypted session PR

[Mark Randall]

On 18/05/2022 16:23, Craig Francis wrote:

If the Session ID continued to work as the Identifier, but the client was given 
the Session ID and a Random Key (could be concatenated together for the 
cookie)... that means the Random Key would not be stored on the server, and 
could protect the session if there was a vulnerability on the server/website 
(e.g. attacker being able to see the directory listing of session files)... I'm 
not sure how much of a benefit that will actually provide, vs the risk of it 
going wrong (e.g. future PHP changing encryption algorithm).



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.


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Early feedback on encrypted session PR

[Craig Francis]

On 17 May 2022, at 23:11, Mark Randall  wrote:
> On 17/05/2022 21:36, David CARLIER wrote:
>> I wanted a more general but early feedback on the idea itself
>> https://github.com/php/php-src/pull/3759
> 
> What is the motivation? What is it meant to achieve?


If the Session ID continued to work as the Identifier, but the client was given 
the Session ID and a Random Key (could be concatenated together for the 
cookie)... that means the Random Key would not be stored on the server, and 
could protect the session if there was a vulnerability on the server/website 
(e.g. attacker being able to see the directory listing of session files)... I'm 
not sure how much of a benefit that will actually provide, vs the risk of it 
going wrong (e.g. future PHP changing encryption algorithm).

Craig

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Early feedback on encrypted session PR

[David CARLIER]

Hi,

I wanted a more general but early feedback on the idea itself
https://github.com/php/php-src/pull/3759

which is encrypting/decrypting the session on the fly with openssl
(assuming as an improvement it would need a more complex key than the
session id to make it more useful and being configurable).

Regards.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php