Everything

php

[RFC] samesite cookie implementation

php.internals

Frederik Bosch | Genkgo

9 years ago

LS,

Today I finished writing the RFC for implementing same site cookies in
PHP, https://wiki.php.net/rfc/same-site-cookie. I am happy to receive
your remarks on the proposal, and improve when necessary.

For those (only) interested in code, have a look at PR # 2613:
https://github.com/php/php-src/pull/2613.

For the record, I am just a messenger in this regard. Someone uploaded a
patch for this feature in bug #72230:
https://bugs.php.net/bug.php?id=72230. I just took the opportunity to
create a PR and the corresponding RFC. Credits for the code go to
xistence at 0x90 dot nl.

Hopefully, the samesite cookie flag will become a feature of the PHP
language through this RFC!

Kind regards,
Frederik Bosch

Andrey Andreev

9 years ago

Hi Frederik,

On Tue, Jul 18, 2017 at 12:11 AM, Frederik Bosch | Genkgo
<f.bosch@genkgo.nl> wrote:

> LS,
>
> Today I finished writing the RFC for implementing same site cookies in PHP,
> https://wiki.php.net/rfc/same-site-cookie. I am happy to receive your
> remarks on the proposal, and improve when necessary.
>
> For those (only) interested in code, have a look at PR # 2613:
> https://github.com/php/php-src/pull/2613.
>
> For the record, I am just a messenger in this regard. Someone uploaded a
> patch for this feature in bug #72230: https://bugs.php.net/bug.php?id=72230.
> I just took the opportunity to create a PR and the corresponding RFC.
> Credits for the code go to xistence at 0x90 dot nl.
>
> Hopefully, the samesite cookie flag will become a feature of the PHP
> language through this RFC!
>

Unfortunately, all of the cons you've explained in the RFC are very
valid concerns.
I'd rather first see what happens with http_cookie_set() that's being
talked about in another thread currently (I suspect inspired by this).

Cheers,
Andrey.

Frederik Bosch | Genkgo

9 years ago

Hi Andrey,

Thanks for your feedback. If we are going to wait for http_cookie_set,
then my guess will be that it will take a while before we see samesite
cookie implemented. While I totally agree there is need for a new
function with a better API, I fail to see why that would mean we cannot
have a samesite argument in the set(raw)cookie functions now. The RFC is
in line with the design of these functions.

With regard to browsers not implementing it, let me quote the currrent
documentation on the httponly argument. "It has been suggested that this
setting can effectively help to reduce identity theft through XSS
attacks (although it is not supported by all browsers), but that claim
is often disputed." Basically it says that it is not supported by all
browsers, but provides help reducing XSS attacks. I don't see the
difference with samesite.

Best,
Frederik



On 18-07-17 12:37, Andrey Andreev wrote:

> Hi Frederik,
>
> On Tue, Jul 18, 2017 at 12:11 AM, Frederik Bosch | Genkgo
> <f.bosch@genkgo.nl> wrote:
>> LS,
>>
>> Today I finished writing the RFC for implementing same site cookies in PHP,
>> https://wiki.php.net/rfc/same-site-cookie. I am happy to receive your
>> remarks on the proposal, and improve when necessary.
>>
>> For those (only) interested in code, have a look at PR # 2613:
>> https://github.com/php/php-src/pull/2613.
>>
>> For the record, I am just a messenger in this regard. Someone uploaded a
>> patch for this feature in bug #72230: https://bugs.php.net/bug.php?id=72230.
>> I just took the opportunity to create a PR and the corresponding RFC.
>> Credits for the code go to xistence at 0x90 dot nl.
>>
>> Hopefully, the samesite cookie flag will become a feature of the PHP
>> language through this RFC!
>>
> Unfortunately, all of the cons you've explained in the RFC are very
> valid concerns.
> I'd rather first see what happens with http_cookie_set() that's being
> talked about in another thread currently (I suspect inspired by this).
>
> Cheers,
> Andrey.

--


Frederik Bosch


Partner

Genkgo logo
Mail: f.bosch@genkgo.nl <mailto:f.bosch@genkgo.nl>
Web: support.genkgo.com <https://support.genkgo.com>

Entrada 123
Amsterdam
+31 208 943 931

Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer
56501153

lists@rhsoft.net

9 years ago

Am 18.07.2017 um 15:23 schrieb Frederik Bosch | Genkgo:

> Hi Andrey,
>
> Thanks for your feedback. If we are going to wait for http_cookie_set,
> then my guess will be that it will take a while before we see samesite
> cookie implemented. While I totally agree there is need for a new
> function with a better API, I fail to see why that would mean we cannot
> have a samesite argument in the set(raw)cookie functions now. The RFC is
> in line with the design of these functions.
>
> With regard to browsers not implementing it, let me quote the currrent
> documentation on the httponly argument. "It has been suggested that this
> setting can effectively help to reduce identity theft through XSS
> attacks (although it is not supported by all browsers), but that claim
> is often disputed." Basically it says that it is not supported by all
> browsers, but provides help reducing XSS attacks. I don't see the
> difference with samesite.

which browser in 2017 does not support 'httponly'?
that was true a decade ago, now that parapgraph in the docs is just FUD

Paul M Jones

9 years ago

> On Jul 18, 2017, at 08:37, lists@rhsoft.net wrote:
>
>
>
> Am 18.07.2017 um 15:23 schrieb Frederik Bosch | Genkgo:
>> Hi Andrey,
>> Thanks for your feedback. If we are going to wait for http_cookie_set, then my guess will be that it will take a while before we see samesite cookie implemented. While I totally agree there is need for a new function with a better API, I fail to see why that would mean we cannot have a samesite argument in the set(raw)cookie functions now. The RFC is in line with the design of these functions.
>> With regard to browsers not implementing it, let me quote the currrent documentation on the httponly argument. "It has been suggested that this setting can effectively help to reduce identity theft through XSS attacks (although it is not supported by all browsers), but that claim is often disputed." Basically it says that it is not supported by all browsers, but provides help reducing XSS attacks. I don't see the difference with samesite.
>
> which browser in 2017 does not support 'httponly'?
> that was true a decade ago, now that parapgraph in the docs is just FUD

(/me nods)

Perhaps the same will be true for "samesite".

--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Andrey Andreev

9 years ago

Hi again,

On Tue, Jul 18, 2017 at 4:23 PM, Frederik Bosch | Genkgo <f.bosch@genkgo.nl>
wrote:

> Hi Andrey,
>
> Thanks for your feedback. If we are going to wait for http_cookie_set,
> then my guess will be that it will take a while before we see samesite
> cookie implemented. While I totally agree there is need for a new function
> with a better API, I fail to see why that would mean we cannot have a
> samesite argument in the set(raw)cookie functions now. The RFC is in line
> with the design of these functions.
>

I don't know what you mean by "now" ... it's not like it can happen
overnight.

With regard to browsers not implementing it, let me quote the currrent

> documentation on the httponly argument. "It has been suggested that this
> setting can effectively help to reduce identity theft through XSS attacks
> (although it is not supported by all browsers), but that claim is often
> disputed." Basically it says that it is not supported by all browsers, but
> provides help reducing XSS attacks. I don't see the difference with
> samesite.
>

Well, if you insist on comparing the two ...

- HttpOnly was released with PHP 5.2.0 in January 2011 - just 3 months
prior to IETF RFC 6265 (April 2011) becoming a standards track.
- SameSite has only a single IETF draft, which has expired because it's
been inactive for a year.


I too want to see SameSite cookies added to PHP's standard library, but
this is certainly not a thing that needs to happen yesterday. There's no
reason not to wait for the http_cookie_set() proposal.

And I too agree that adding a millionth parameter to setcookie() is the
wrong approach anyway.

Cheers,
Andrey.

Andrey Andreev

9 years ago

Hi,

Not realizing I was looking at EOL dates, I (unintentionally) provided
some wrong info yesterday:

On Tue, Jul 18, 2017 at 5:13 PM, Andrey Andreev <narf@devilix.net> wrote:

>
> - HttpOnly was released with PHP 5.2.0 in January 2011 - just 3 months prior
> to IETF RFC 6265 (April 2011) becoming a standards track.

PHP 5.2 was of course released way back, in 2006. My apologies for that.

Cheers,
Andrey.

Frederik Bosch | Genkgo

9 years ago

Hi Andrey,

Thanks for you remark. If I understand correctly, PHP was 4-5 years
ahead of HttpOnly becoming an actual standard. What a leaders they were
back then.

Best,
Frederik

On 19-07-17 17:06, Andrey Andreev wrote:

Frederik Bosch | Genkgo

9 years ago

LS,

All concerns that have been put forward are updated in the RFC document.
See https://wiki.php.net/rfc/same-site-cookie. I am going to start the
voting on August 1, 2017. Exactly two weeks after I posted the RFC on
the internals list. If new concerns are put forward in the meanwhile, I
will of course update the RFC.

Best,
Frederik




On 19-07-17 17:06, Andrey Andreev wrote:

> Hi,
>
> Not realizing I was looking at EOL dates, I (unintentionally) provided
> some wrong info yesterday:
>
> On Tue, Jul 18, 2017 at 5:13 PM, Andrey Andreev <narf@devilix.net> wrote:
>> - HttpOnly was released with PHP 5.2.0 in January 2011 - just 3 months prior
>> to IETF RFC 6265 (April 2011) becoming a standards track.
> PHP 5.2 was of course released way back, in 2006. My apologies for that.
>
> Cheers,
> Andrey.

--


Frederik Bosch


Partner

Genkgo logo
Mail: f.bosch@genkgo.nl <mailto:f.bosch@genkgo.nl>
Web: support.genkgo.com <https://support.genkgo.com>

Entrada 123
Amsterdam
+31 208 943 931

Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer
56501153

Frederik Bosch | Genkgo

9 years ago

LS,

Because of the valid arguments to set(raw)cookie and
session_set_cookie_params to become lengthly functions, I reconsidered
the proposal. It now consists of two possibilities. One is add samesite
as argument and second one is to have these functions accept an array of
options. One can read the changes in the proposal
https://wiki.php.net/rfc/same-site-cookie.

When both solutions will be rejected, the floor will be completely open
for the proposal of http_cookie_set/remove since we then investigated
all the possible solutions to the current set of functions.

Best,
Frederik



On 20-07-17 10:10, Frederik Bosch | Genkgo wrote:

>
> LS,
>
> All concerns that have been put forward are updated in the RFC
> document. See https://wiki.php.net/rfc/same-site-cookie. I am going to
> start the voting on August 1, 2017. Exactly two weeks after I posted
> the RFC on the internals list. If new concerns are put forward in the
> meanwhile, I will of course update the RFC.
>
> Best,
> Frederik
>
>
>
>
> On 19-07-17 17:06, Andrey Andreev wrote:
>> Hi,
>>
>> Not realizing I was looking at EOL dates, I (unintentionally) provided
>> some wrong info yesterday:
>>
>> On Tue, Jul 18, 2017 at 5:13 PM, Andrey Andreev<narf@devilix.net>  wrote:
>>> - HttpOnly was released with PHP 5.2.0 in January 2011 - just 3 months prior
>>> to IETF RFC 6265 (April 2011) becoming a standards track.
>> PHP 5.2 was of course released way back, in 2006. My apologies for that.
>>
>> Cheers,
>> Andrey.
>
> --
>
>
>     Frederik Bosch
>
>
>       Partner
>
> Genkgo logo
> Mail: f.bosch@genkgo.nl <mailto:f.bosch@genkgo.nl>
> Web: support.genkgo.com <https://support.genkgo.com>
>
> Entrada 123
> Amsterdam
> +31 208 943 931
>
> Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder
> nummer 56501153

--


Frederik Bosch


Partner

Genkgo logo
Mail: f.bosch@genkgo.nl <mailto:f.bosch@genkgo.nl>
Web: support.genkgo.com <https://support.genkgo.com>

Entrada 123
Amsterdam
+31 208 943 931

Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer
56501153

Lars Strojny

9 years ago

Hi everybody,

I strongly believe this is something we should ship with 7.2. That would give the ecosystem a 1-year head with a feature that could eventually help eradicate CSRF. I would argue that this is worth the unorthodox circumnavigation of our policies. Do you think that’s outrageously crazy?

cu,
Lars

On 24.07.17, 10:53, "Frederik Bosch | Genkgo" <f.bosch@genkgo.nl> wrote:

LS,

Because of the valid arguments to set(raw)cookie and

session_set_cookie_params to become lengthly functions, I reconsidered

the proposal. It now consists of two possibilities. One is add samesite

as argument and second one is to have these functions accept an array of

options. One can read the changes in the proposal

https://wiki.php.net/rfc/same-site-cookie.

When both solutions will be rejected, the floor will be completely open

for the proposal of http_cookie_set/remove since we then investigated

all the possible solutions to the current set of functions.

Best,

Frederik

On 20-07-17 10:10, Frederik Bosch | Genkgo wrote:

LS,

All concerns that have been put forward are updated in the RFC

document. See https://wiki.php.net/rfc/same-site-cookie. I am going to

start the voting on August 1, 2017. Exactly two weeks after I posted

the RFC on the internals list. If new concerns are put forward in the

meanwhile, I will of course update the RFC.

Best,

Frederik

On 19-07-17 17:06, Andrey Andreev wrote:

Hi,

Not realizing I was looking at EOL dates, I (unintentionally) provided

some wrong info yesterday:

On Tue, Jul 18, 2017 at 5:13 PM, Andrey Andreev<narf@devilix.net>  wrote:

- HttpOnly was released with PHP 5.2.0 in January 2011 - just 3 months prior

to IETF RFC 6265 (April 2011) becoming a standards track.

PHP 5.2 was of course released way back, in 2006. My apologies for that.

Cheers,

Andrey.

--

Frederik Bosch

Partner

Genkgo logo

Mail: f.bosch@genkgo.nl <mailto:f.bosch@genkgo.nl>

Web: support.genkgo.com <https://support.genkgo.com>

Entrada 123

Amsterdam

+31 208 943 931

Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder

nummer 56501153

--

Frederik Bosch

Partner

Genkgo logo

Mail: f.bosch@genkgo.nl <mailto:f.bosch@genkgo.nl>

Web: support.genkgo.com <https://support.genkgo.com>

Entrada 123

Amsterdam

+31 208 943 931

Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer

56501153

Christoph Becker

9 years ago

On 25.08.2017 at 22:54, Lars Strojny wrote:

> I strongly believe this is something we should ship with 7.2. That
> would give the ecosystem a 1-year head with a feature that could
> eventually help eradicate CSRF. I would argue that this is worth the
> unorthodox circumnavigation of our policies. Do you think that’s
> outrageously crazy?

Considering the current browser support
(https://caniuse.com/#search=samesite), I am not convinced that any rush
is appropriate.  In the worst case, developers might rely on this
feature, while in fact the option is ignored by many browsers, and as
such gives a false sense of security.

--
Christoph M. Becker

Marco Pivetta

9 years ago

Hey Andrey,
On Mon, Jul 17, 2017 at 11:11 PM, Frederik Bosch | Genkgo <f.bosch@genkgo.nl

> wrote:

> LS,
>
> Today I finished writing the RFC for implementing same site cookies in
> PHP, https://wiki.php.net/rfc/same-site-cookie. I am happy to receive
> your remarks on the proposal, and improve when necessary.
>
> For those (only) interested in code, have a look at PR # 2613:
> https://github.com/php/php-src/pull/2613.
>
> For the record, I am just a messenger in this regard. Someone uploaded a
> patch for this feature in bug #72230: https://bugs.php.net/bug.php?i
> d=72230. I just took the opportunity to create a PR and the corresponding
> RFC. Credits for the code go to xistence at 0x90 dot nl.
>
> Hopefully, the samesite cookie flag will become a feature of the PHP
> language through this RFC!
>

The current `setcookie` method has 7 parameters, of which 6 are optional.
This is already a mess, as any default value change introduced for either
forward-compliance or security issue compliance would result in a BC break.

This RFC suggests adding even more parameters (URGH), and increasing the
issue impact.

I had already expressed this issue in https://wiki.php.net/rfc/openssl_aead,
which made the `openssl_encrypt` endpoint a mess to deal with: an
n-dimensional space of optional parameters and possible method behavior
combinations :-P
Imagine all the picturesque ways that people could come up with to do
crypto the wrong way! Fascinating!

Creating a cookie string in userland is trivial, and the `setcookie`
functionality should just be left alone and maybe deprecated, IMO.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

lists@rhsoft.net

9 years ago

Am 18.07.2017 um 15:45 schrieb Marco Pivetta:

> Hey Andrey,
> On Mon, Jul 17, 2017 at 11:11 PM, Frederik Bosch | Genkgo <f.bosch@genkgo.nl
>> wrote:
>
>> LS,
>>
>> Today I finished writing the RFC for implementing same site cookies in
>> PHP, https://wiki.php.net/rfc/same-site-cookie. I am happy to receive
>> your remarks on the proposal, and improve when necessary.
>>
>> For those (only) interested in code, have a look at PR # 2613:
>> https://github.com/php/php-src/pull/2613.
>>
>> For the record, I am just a messenger in this regard. Someone uploaded a
>> patch for this feature in bug #72230: https://bugs.php.net/bug.php?i
>> d=72230. I just took the opportunity to create a PR and the corresponding
>> RFC. Credits for the code go to xistence at 0x90 dot nl.
>>
>> Hopefully, the samesite cookie flag will become a feature of the PHP
>> language through this RFC!
>
> The current `setcookie` method has 7 parameters, of which 6 are optional.
> This is already a mess, as any default value change introduced for either
> forward-compliance or security issue compliance would result in a BC break.
>
> This RFC suggests adding even more parameters (URGH), and increasing the
> issue impact.
>
> I had already expressed this issue in https://wiki.php.net/rfc/openssl_aead,
> which made the `openssl_encrypt` endpoint a mess to deal with: an
> n-dimensional space of optional parameters and possible method behavior
> combinations :-P
> Imagine all the picturesque ways that people could come up with to do
> crypto the wrong way! Fascinating!
>
> Creating a cookie string in userland is trivial, and the `setcookie`
> functionality should just be left alone and maybe deprecated, IMO

i don't share your optinion, especially talking about 'should be
deprecated' where i get the feeling some peoples hobby is deprecate
working things

comparing cookie params with encryption is hopefully just kidding

Marco Pivetta

9 years ago

On Tue, Jul 18, 2017 at 3:50 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:

> i don't share your optinion, especially talking about 'should be
> deprecated' where i get the feeling some peoples hobby is deprecate working
> things
>
> comparing cookie params with encryption is hopefully just kidding
>

It could be a "hello world" function - same stuff.

Also, yes, cookies are as security-sensitive stuff as crypto, if not often
more (since crypto is usually handled at webserver level, and direct usage
of openssl is more "rare")

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

lists@rhsoft.net

9 years ago

Am 18.07.2017 um 16:00 schrieb Marco Pivetta:

> On Tue, Jul 18, 2017 at 3:50 PM, lists@rhsoft.net
> <mailto:lists@rhsoft.net> <lists@rhsoft.net <mailto:lists@rhsoft.net>>
> wrote:
>
>     i don't share your optinion, especially talking about 'should be
>     deprecated' where i get the feeling some peoples hobby is deprecate
>     working things
>
>     comparing cookie params with encryption is hopefully just kidding
>
>
> It could be a "hello world" function - same stuff.
>
> Also, yes, cookies are as security-sensitive stuff as crypto, if not
> often more (since crypto is usually handled at webserver level, and
> direct usage of openssl is more "rare")

how can they than be more security-sensitive within the encryption
layer.... but that's not the point: setcookie() even with all it's
params is easy and clear to use fopr anybody which has a clue what he is
doing and there is no need to deprecated it nor design a new shiny API
for it as replacement

Frederik Bosch | Genkgo

9 years ago

Hi Marco,

Great feedback. I have to think about it, but your concerns are valid
for sure. The RFC is, however, broader then only setcookie and
setrawcookie. How about session_set/get_cookie_params? Would you be able
to accept the RFC if samesite would only be added to session? Why or why
not?

Frederik

On 18-07-17 15:45, Marco Pivetta wrote:

Marco Pivetta

9 years ago

Hey Andrey,
On Mon, Jul 17, 2017 at 11:11 PM, Frederik Bosch | Genkgo <f.bosch@genkgo.nl

> wrote:

> LS,
>
> Today I finished writing the RFC for implementing same site cookies in
> PHP, https://wiki.php.net/rfc/same-site-cookie. I am happy to receive
> your remarks on the proposal, and improve when necessary.
>
> For those (only) interested in code, have a look at PR # 2613:
> https://github.com/php/php-src/pull/2613.
>
> For the record, I am just a messenger in this regard. Someone uploaded a
> patch for this feature in bug #72230: https://bugs.php.net/bug.php?i
> d=72230. I just took the opportunity to create a PR and the corresponding
> RFC. Credits for the code go to xistence at 0x90 dot nl.
>
> Hopefully, the samesite cookie flag will become a feature of the PHP
> language through this RFC!
>

The (already) infinite signature of this function just adds up some more
scenarios where BC compliance becomes a problem.

The current `setcookie` method has 7 parameters, of which 6 are optional.
This is already a mess, as any default value change introduced for either
forward-compliance or security issue compliance would result in a BC break.

This RFC suggests adding even more parameters (URGH), and increasing the
issue impact.

I had already expressed this issue in https://wiki.php.net/rfc/openssl_aead,
which basically passed

Honestly, API


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/