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
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.
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
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
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
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)
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
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.
Hi,
Not realizing I was looking at EOL dates, I (unintentionally) provided
some wrong info yesterday:
- 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.
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
Hi,
Not realizing I was looking at EOL dates, I (unintentionally) provided
some wrong info yesterday:
- 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.
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
Hi,
Not realizing I was looking at EOL dates, I (unintentionally) provided
some wrong info yesterday:
- 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
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
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,
FrederikHi,
Not realizing I was looking at EOL dates, I (unintentionally) provided
some wrong info yesterday:
- 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 PartnerGenkgo logo
Mail: f.bosch@genkgo.nl mailto:f.bosch@genkgo.nl
Web: support.genkgo.com https://support.genkgo.comEntrada 123
Amsterdam
+31 208 943 931Genkgo 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
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
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
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
Hi,
Not realizing I was looking at EOL dates, I (unintentionally) provided
some wrong info yesterday:
- 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
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
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
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.nlwrote:
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
setcookiemethod 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 theopenssl_encryptendpoint 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
i don't share your optinion, especially talking about 'should be
deprecated' where i get the feeling some peoples hobby is deprecate working
thingscomparing 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
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 kiddingIt 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
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
Hey Andrey,
On Mon, Jul 17, 2017 at 11:11 PM, Frederik Bosch | Genkgo
<f.bosch@genkgo.nl mailto: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 <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 <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 <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!The current
setcookiemethod 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_encryptendpoint 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
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