rfc:same-site-cookie

This is an old revision of the document!


PHP RFC: Same Site Cookie

  • Version: 0.9
  • Date: 2017-07-16
  • Author of RFC and creator of PR: Frederik Bosch, f.bosch@genkgo.nl
  • Author of original patch: xistence at 0x90 dot nl
  • Status: Draft

Introduction

Same-site cookies allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain. The technology is currently a proposed web standard. However, same site cookies are already adopted by Chrome and planned by planned by Firefox. Major PHP frameworks already implemented this through a custom Set-Cookie header call. The RFC will try to convince voters that same site cookies should be available as a core language feature.

How the samesite flag works

Cookies are issued using the Set-Cookie header. When issuing a cookie, one can set a key and value together with flags for the browser to determine whether the cookie should be accessible. A typical cookie might look like this.

Set-Cookie: key=value; path=/; domain=example.org; HttpOnly

As many will know, this opens doors for CSRF attacks, an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. Authentication state is saved through the use of (session) cookies. The cookie is the key for having access to the application. When using samesite, the developer can specify if and when the cookie should be accessible when a request originates from another registrable domain.

According to the proposed standard, there are now two possibilities for a cookie that is using the samesite flag: “Lax” and “Strict”. The difference between Lax and Strict is the accessibility of the cookie in requests originating from another registrable domain using the HTTP GET method. Cookies using Lax will be accessible in a GET request originated from another registrable domain, whereas cookies using Strict will not be accessible in a GET request originated from another registrable domain. There is no difference with POST methods: the browser should not allow the cookie to be accessed in a POST request originating from another registrable domain.

A cookie that is issued using the samesite flag, might look as follows.

Set-Cookie: key=value; path=/; domain=example.org; HttpOnly; SameSite=Lax

Proposal

In order to add this samesite flag when issuing cookies, four core functions will be affected by this RFC.

  1. setcookie
  2. setrawcookie
  3. session_set_cookie_params
  4. session_get_cookie_params

setcookie

The setcookie function will get an extra argument samesite.

bool setcookie ( string $name [, string $value = "" [, int $expire = 0 [, string $path = "" [, string $domain = "" [, bool $secure = false [, bool $httponly = false [, string $samesite = "" ]]]]]]] )

setrawcookie

The setrawcookie function will get an extra argument samesite.

bool setrawcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false [, string $samesite = "" ] ]]]]]] )

The session_set_cookie_param function will get an extra argument samesite.

void session_set_cookie_params ( int $lifetime [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false [, string $samesite = "" ]]]]] )

The return value of the session_get_cookie_params function will have an extra key samesite in the returned array.

array(
  "lifetime" => 0,             // The lifetime of the cookie in seconds.
  "path" => "/",               // The path where information is stored.
  "domain" => "example.org",   // The domain of the cookie.
  "secure" => true,            // The cookie should only be sent over secure connections.
  "httponly" => true,          // The cookie can only be accessed through the HTTP protocol.
  "samesite" => "Strict"       // The cookie can only be accessed if it was initiated from the same registrable domain.
)

Pros and cons: why or why not to adopt this RFC

The first and foremost reasons to accept this RFC is that developers will be able to better secure their PHP applications. It fits the step PHP is already making with the upcoming availability of libsodium. With this feature, the language would make another step in helping developers to write secure code.

But, there is a risk involved. The samesite cookie might not become a standard which might lead browsers to eventually drop the flag. If that would be the case, the setcookie, setrawcookie and session_set_cookie_params functions would have a useless samesite argument.

The author believes strongly that the pros weigh up to the cons. At this moment more than 50% of the global used browsers support the samesite flag. And another major browser is already working on it. How many PHP installations could we make more secure? Privacy and security are of a higher concern than the risk of ending up with one useless argument to three core functions.

Backward Incompatible Changes

There are no backward incompatible changes.

Proposed PHP Version(s)

next PHP 7.x

RFC Impact

php.ini defaults

The following ini values will be added.

  • session.cookie_samesite

The default value is the empty string in both default development and production php.ini.

Proposed Voting Choices

This RFC requires a 50%+1 majority.

Patches and Tests

References

rfc/same-site-cookie.1500326229.txt.gz · Last modified: 2017/09/22 13:28 (external edit)