Re: [RFC] samesite cookie implementation

From: Date: Tue, 18 Jul 2017 13:57:19 +0000
Subject: Re: [RFC] samesite cookie implementation
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-99898@lists.php.net to get a copy of this message
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:
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 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/


« previous php.internals (#99898) next »