PHP setcookie “SameSite=Strict”?

[Important update: As @caw pointed out below, this hack WILL BREAK in PHP 7.3. Stop using it now to save yourself from unpleasant surprises! Or at least wrap it in a PHP version check like if (PHP_VERSION_ID < 70300) { ... } else { ... }.]

It seems like you can abuse the "path" or "domain" parameter of PHP's "setcookie" function to sneak in the SameSite attribute because PHP does not escape semicolons:

setcookie('samesite-test', '1', 0, '/; samesite=strict');

Then PHP sends the following HTTP header:

Set-Cookie: samesite-test=1; path=/; samesite=strict

I've just discovered this a few minutes ago, so please do your own testing! I'm using PHP 7.1.11.

Make sure you have a domain that is known by both server and client. echo $_SERVER['HTTP_HOST'] should tell you the exact same domain that your browser has. If not, cookie will not be accepted by the browser.

Make sure your server and client time is perfectly correct. Browser will reject a cookie with a wrong datetime.

Do not write any other code and just do:

<?php
$cookie_name = "user";
$cookie_value = "John Doe";
setcookie($cookie_name, $cookie_value, time() + (86400 * 30), "/"); // 86400 = 1 day 
// expiration
echo date("H:i:s d.m.Y")."<br>";
echo $_SERVER['HTTP_HOST']."<br>";
var_dump($_COOKIE);
?>

and refresh the page twice.

Also check out manual at: https://www.php.net/manual/en/features.cookies.php

Don't store the password in the cookie, hashed or not. In fact, there's no reason to store anything sensitive in the cookie. All you need to do is map a 128-bit (or larger) random id to a user account in your database, and store that id in the cookie. There is no way somebody is going to guess a valid id by remote brute force, especially if you have lock-outs in place.

If someone were to gain access to the cookies and they copy them to a different computer, and then try accessing the website from that computer, theoretically, it will automatically log them in to that user's account, is this not a security issue?

Yes. That's the downside to the feature. However, if your website detects new IP address (particularly from different countries) and requires a second step (text a code to a mobile device, etc), then you take care of this problem along with the general problem of a stolen password. (This of course doesn't help prevent local network attacks, like an insecure public wifi.)

A more convenient solution is to require the "remember me" cookie to use SSL. That way a hacker would not ever see the cookie in plain text transmission, and a local attack would probably be required. (And if such, the remember me cookie is probably the least of the user's concerns.)

they can effectively get access to any account they want, rendering the whole password-hashing process as useless.

Yes, and no. If you use the technique I described (random id) then they can only access accounts that have a "remember me" cookie. But that said, if they have access to your database, they can brute force any account they want. Even salted passwords are easy to crack locally if the password itself is weak.

Also, you can consider the "remember me" login to be a half-login. Access to purchase something, change an email address, etc, would still require a password to be entered. Doing harmless things like posting on a message board could be done without the password.

Finally, note that a PHP session cookie is nothing more than a temporary "remember me" token! So much of this applies to the concept of session hijacking. The "remember me" token simply adds a bigger window of opportunity.

So in short: don't store anything sensitive in the cookie, require SSL for the cookie, and if possible, implement multi-factor authentication ... especially for admin accounts.