Core: Cookies must be set with the Secure flag in HTTPS mode

[hardware]

All cookies should be created such that their access is as limited as possible. This can help minimize damage from cross-site scripting (XSS) vulnerabilities, as these cookies often contain session identifiers or other sensitive information. Session cookies sent from secure sites must be explicitly marked as secure to prevent being obtained by active network attackers.

In HTTPS mode, all cookies must be set with the Secure flag, indicating that they should only be sent over encrypted channel.

SetCookie::create($session->getName(), $session->getId())
                ->withPath('/')
                ->withHttpOnly(true)
                ->withSecure(true)

Transmission over HTTP prevented by HSTS mechanism in our case but it might be a good idea to add this flag in HTTPS mode by default in flarum core.

[datitisev]

Should this be closed now?

[sijad]

no I guess, this should be done for other important cookies too, also I think withSecure breaks Flarum for non https sites, this should be omitted for non https sites.

[hardware]

This must be done for session cookies (or any other sensitive data) and also advisable for others cookies (e.g flarum_remember).

When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS [RFC2818]).

https://tools.ietf.org/html/rfc6265#section-4.1.2.5

Actually, https://github.com/flarum/core/pull/1085 breaks non HTTPS sites.

[tobyzerner]

Hence my question in #1085 ("Does this cause any problems when HTTPS is not being used?")...

Would someone mind doing a PR to fix that?

[hardware]

The session cookie appears twice in the HTTP headers since the last version with our forum, same as discuss.flarum.org :

curl -I https://discuss.flarum.org/

HTTP/2 200 
server: nginx/1.11.9
date: Fri, 09 Feb 2018 21:12:46 GMT
content-type: text/html; charset=utf-8
vary: Accept-Encoding
cache-control: max-age=0, private, must-revalidate
set-cookie: flarum_session=xxxxxxx; path=/
set-cookie: flarum_session=xxxxxxx; Path=/; Secure; HttpOnly
x-csrf-token: xxxxxx
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff

One is secure, other is not.

Any idea ?

[tobyzerner]

Nice spot. Looks like this is a bug in our StartSession middleware, where PHP is sending a session cookie (as $_SESSION is set via Symfony NativeSessionStorage), and then we're also sending our own secure version of the cookie. This should be refactored to set $options on Symfony's NativeSessionStorage to make the native cookie secure.