[RFC] [Discussion] Deprecate GET/POST sessions

Rob Landers

2 years ago

On Sat, Mar 2, 2024, at 22:10, Kamil Tekiela wrote:

> Hi Internals,
>
> I would like to start a discussion on a new RFC
> https://wiki.php.net/rfc/deprecate-get-post-sessions
>
> Please let me know whether the idea is clear and the RFC is understandable.
>
> In particular, I am looking for any feedback as to why this is a bad
> idea. The primary motivation behind this RFC is to reduce potential
> security pitfalls.
>
> Regards,
> Kamil Tekiela
>

For what it is worth, I’ve used this with great success on Google’s http-based job system in their cloud. Whether that is a good idea or not, I have no idea. But I suspect I’m not the only one that has relied on this behavior.

— Rob

Gina P. Banyard

2 years ago

On Saturday, 2 March 2024 at 21:10, Kamil Tekiela <tekiela246@gmail.com> wrote:

> Hi Internals,
>
> I would like to start a discussion on a new RFC
> https://wiki.php.net/rfc/deprecate-get-post-sessions
>
> Please let me know whether the idea is clear and the RFC is understandable.
>
> In particular, I am looking for any feedback as to why this is a bad
> idea. The primary motivation behind this RFC is to reduce potential
> security pitfalls.
>
> Regards,
> Kamil Tekiela

I think this makes sense to me.
I would possibly move the deprecation of the SID constant from the mass deprecation RFC to this one, as I would be very odd to have this accepted but not the latter.

Best regards,

Gina P. Banyard

Kamil Tekiela

2 years ago

---------- Forwarded message ---------
From: Anton Smirnov <arokettu@outlook.com>
Date: Sun, 3 Mar 2024 at 19:56
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
To: Kamil Tekiela <tekiela246@gmail.com>

Greetings!

I'm sorry for addressing you directly, if you can forward this message
to internals I'd be grateful. It seems outlook is still banned and I
can't re-subscribe with any other email (tried outlook, gmail, vivaldi
and a small private service)

On 02/03/2024 23:10, Kamil Tekiela wrote:

> Hi Internals,
>
> I would like to start a discussion on a new RFC
> https://wiki.php.net/rfc/deprecate-get-post-sessions
>
> Please let me know whether the idea is clear and the RFC is

understandable.

>
> In particular, I am looking for any feedback as to why this is a bad
> idea. The primary motivation behind this RFC is to reduce potential
> security pitfalls.
>
> Regards,
> Kamil Tekiela

Greetings!

As I know some session-related middlewares force custom-only session_id
handling by setting

use_cookies = Off
use_only_cookies = On

and then using session_id(...) directly

Example:
https://github.com/middlewares/php-session/blob/master/src/PhpSession.php#L137

I think if you're making this hack impossible, you should provide an
alternative non-hackish way to do this.

Maybe just keep use_cookies = Off

A wild idea:

1) Add a temporary config

# by default; current behavior;
# throws a deprecation right from the introduction
cookies.use_post_get = On
# do not set the session from POST and GET
cookies.use_post_get = Off

Remove it in 9 with the rest

2) keep use_cookies in PHP 9 with the updated meaning

I don't think it's a good solution but maybe it can spark a better one

Best,
Anton

Kamil Tekiela

2 years ago

Hi Anton,

> As I know some session-related middlewares force custom-only session_id
> handling by setting
>
>    use_cookies = Off
>    use_only_cookies = On
>
> and then using session_id(...) directly
>
> Example:
> https://github.com/middlewares/php-session/blob/master/src/PhpSession.php#L137

I was not aware that some frameworks do that. But I don't understand
how this works. IMHO if you disable the use of cookies, but you also
tell PHP to use only cookies it creates an impossible scenario. Isn't
that right?

The way I understand it is that there are 2 ways of propagating
session ID: cookies and GET/POST. You can tell PHP to use both or
either one of them, but not neither.

Only cookies:
use_only_cookies = On
use_cookies = On

Only GET/POST:
use_only_cookies = Off
use_cookies = Off

Both:
use_only_cookies = Off
use_cookies = On

The remaining 4th combination should create an impossible scenario.
Does it mean to use neither option?

I can change the proposal to deprecate only use_only_cookies=Off and
session.use_trans_sid=On and leave session.use_cookies alone, but I
just can't think of a situation when leaving that setting in PHP would
make sense.

I am probably missing something very important and I would appreciate
it if someone could explain to me what it is. I wouldn't want to
deprecate something that is used in popular frameworks.

Anton Smirnov

2 years ago

On 03/03/2024 23:33, Kamil Tekiela wrote:

> Hi Anton,
>
>> As I know some session-related middlewares force custom-only session_id
>> handling by setting
>>
>>     use_cookies = Off
>>     use_only_cookies = On
>>
>> and then using session_id(...) directly
>>
>> Example:
>>

https://github.com/middlewares/php-session/blob/master/src/PhpSession.php#L137

>
> I was not aware that some frameworks do that. But I don't understand
> how this works. IMHO if you disable the use of cookies, but you also
> tell PHP to use only cookies it creates an impossible scenario. Isn't
> that right?
>
> The way I understand it is that there are 2 ways of propagating
> session ID: cookies and GET/POST. You can tell PHP to use both or
> either one of them, but not neither.
>
> Only cookies:
> use_only_cookies = On
> use_cookies = On
>
> Only GET/POST:
> use_only_cookies = Off
> use_cookies = Off
>
> Both:
> use_only_cookies = Off
> use_cookies = On
>
> The remaining 4th combination should create an impossible scenario.
> Does it mean to use neither option?
>
> I can change the proposal to deprecate only use_only_cookies=Off and
> session.use_trans_sid=On and leave session.use_cookies alone, but I
> just can't think of a situation when leaving that setting in PHP would
> make sense.
>
> I am probably missing something very important and I would appreciate
> it if someone could explain to me what it is. I wouldn't want to
> deprecate something that is used in popular frameworks.

Hi Kamil

The remaining 4th combination creates the situation when session
creation is always a responsibility of the userland code.
(by using session_id($id))

In the link I provided it is done by PSR-7/15 purists that think that
only the request emitter should handle headers, not PHP itself and it
includes cookie headers.

For non-purists it is still a useful scenario, for example it allowed to
use SameSite attribute on a session cookie before PHP 7.3

Mel Dafert

2 years ago

>From: Anton Smirnov <arokettu@outlook.com>
>Date: Sun, 3 Mar 2024 at 19:56
>
>Greetings!
>
>As I know some session-related middlewares force custom-only session_id
>handling by setting
>
>   use_cookies = Off
>   use_only_cookies = On
>
>and then using session_id(...) directly
>
>Example:
>https://github.com/middlewares/php-session/blob/master/src/PhpSession.php#L137
>
>I think if you're making this hack impossible, you should provide an
>alternative non-hackish way to do this.
>
>Maybe just keep use_cookies = Off
>
>A wild idea:
>
>1) Add a temporary config
>
>   # by default; current behavior;
>   # throws a deprecation right from the introduction
>   cookies.use_post_get = On
>   # do not set the session from POST and GET
>   cookies.use_post_get = Off
>
>Remove it in 9 with the rest
>
>2) keep use_cookies in PHP 9 with the updated meaning
>
>I don't think it's a good solution but maybe it can spark a better one
>
>Best,
>Anton

I think the better option is to make this explicit and add a config along the lines of `automatic_session_detection` (name to be bikeshed) defaulting to `On`, and in your use-case setting it to `Off` explicitly.

Regards,
Mel

Kamil Tekiela

2 years ago

Hi Everyone,

Upon consideration of your comments, I have decided to adjust my RFC.
Please see the updated version
https://wiki.php.net/rfc/deprecate-get-post-sessions

Changes include:
- session.use_cookies will not be deprecated
- session.trans_sid_tags, session.trans_sid_hosts,
session.referer_check will get deprecated too (although I am not sure
how to implement the deprecation message yet)
- the SID constant will also be deprecated as part of this RFC
- mentioned that output_add_rewrite_var() will remain unaffected

Regards,
Kamil

Kamil Tekiela

2 years ago

If there are no more comments, I would like to put this RFC to vote in
the next two days.

Claude Pache

2 years ago

> Le 4 avr. 2024 à 01:08, Kamil Tekiela <tekiela246@gmail.com> a écrit :
>
> If there are no more comments, I would like to put this RFC to vote in
> the next two days.

Hi,

1. In session_start(), it is possible to override ini settings like that:

```php
session_start([ 'use_cookies' => '1', 'use_only_cookies' => '1', 'referer_check' => '' ]);
```

The relevant options should also be deprecated in that context.

2. A clarification: Suppose that I have  `session.use_only_cookie = 1` in my ini file (no deprecation warning), and I call `ini_set("session.use_only_cookie", "1")` in my code (no-op). Will the `ini_set(...)` invocation trigger a deprecation warning?

—Claude

Kamil Tekiela

2 years ago

>1. In session_start(), it is possible to override ini settings like that:
>
>```php
>session_start([ 'use_cookies' => '1', 'use_only_cookies' => '1', 'referer_check' => '' ]);
>```
>
>The relevant options should also be deprecated in that context.

Yes, they are. You can see that in my draft PR
https://github.com/php/php-src/pull/13578

> 2. A clarification: Suppose that I have  `session.use_only_cookie = 1` in my ini file (no deprecation warning), and I call `ini_set("session.use_only_cookie", "1")` in my code (no-op). Will the `ini_set(...)` invocation trigger a deprecation warning?

As mentioned in the RFC, only changing the option to the deprecated
value triggers the deprecation. You can verify this using my draft PR.
Similarly, if your INI file triggers a deprecations due to for example
session.use_only_cookie=0 and then in your PHP file you change it
using ini_set("session.use_only_cookie", "1") or using the argument to
session_start(), it will only trigger the deprecation during startup
and not during runtime of the script.

Ayesh - PHP.Watch

2 years ago

>
> Hi Internals,
>
> I would like to start a discussion on a new RFC
> https://wiki.php.net/rfc/deprecate-get-post-sessions
>
> Please let me know whether the idea is clear and the RFC is understandable.
>
> In particular, I am looking for any feedback as to why this is a bad
> idea. The primary motivation behind this RFC is to reduce potential
> security pitfalls.
>
> Regards,
> Kamil Tekiela

Hi Kamil,

I quite like the idea, and I think the RFC motivation, impact, and the
scope is clear as well.

The PHP 8.4 deprecations RFC also proposes to deprecate SID constant;
perhaps it's something worth mentioning in this RFC too?

Weirdan

2 years ago

Hi Kamil

On Mon, Mar 4, 2024 at 4:43 PM Kamil Tekiela <tekiela246@gmail.com> wrote:

> I would like to start a discussion on a new RFC
> https://wiki.php.net/rfc/deprecate-get-post-sessions
>
> Please let me know whether the idea is clear and the RFC is understandable.

It would probably make sense to also list `session.trans_sid_tags` and
`session.trans_sid_hosts` as
deprecated. And mentioning that `output_add_rewrite_var()` is
unaffected wouldn't harm either.

--
Best regards,
Bruce Weirdan                                     mailto:weirdan@gmail.com