This repository has been archived on 2023-08-20. You can view files and clone it, but cannot push or open issues or pull requests.
Go to file
Fabien Potencier 51eb41b4c6 bug #32455 [HttpFoundation] Clear invalid session cookie (Toflar)
This PR was submitted for the 4.2 branch but it was squashed and merged into the 4.3 branch instead (closes #32455).

Discussion
----------

[HttpFoundation] Clear invalid session cookie

| Q             | A
| ------------- | ---
| Branch?       | 4.2 (actually maybe should also go to 3.4, see below)
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | TODO
| Fixed tickets |
| License       | MIT
| Doc PR        | not required

Currently, invalid session cookies are not cleaned up.

If the session is empty, the `AbstractSessionHandler::write()` destroys the session. If a new session has been started in the current process (meaning `session_start()` has sent the `Set-Cookie` header) then the `AbstractSessionHandler` will make sure this cookie is not sent to the client. If, however, `session_start()` did not send a cookie (meaning there was already a valid session ID in your request cookie), the `AbstractSessionHandler` will clear the session cookie (send a 0-lifetime cookie).
If, however, the request does contain a session ID cookie but it is not valid, `session_start()` will send a new cookie which is then again cleared by the `AbstractSessionHandler`. But it will not clear the old cookie sent by the request.

Here's a more complex example of what happens in the code flow when a user logs out and we regenerate a new session id for security reasons:

1. You have no `PHPSESSID` cookie yet.
2. You log into the system, you get a new `PHPSESSID` assigned. Let's go for session ID `1`.
3. You log out of the system, for security reasons you get session ID `2` regenerated.
4. The `AbstractSessionListener` pops in and calls `->save()` on your session handler.
5. The `NativeSessionStorage` calls the `StrictSessionHandler` (in fact the abstract parent, `AbstractSessionHandler`) which `write()`s the session data. In case the session data is empty, it will actually `destroy()` the session which means it will invalidate the session cookie. In that case, however, it won't send a 0-lifetime cookie because `$cookie = SessionUtils::popSessionCookie($this->sessionName, $sessionId);` will **not** return `null`. That is because after regeneration we actually do have a `Set-Cookie: PHPSESSID=2` header present.
6. This means, our `PHPSESSID=1` cookie is never deleted.

Why is this a problem?
Well, we have an invalid cookie that remains floating around forever. Loads of reverse proxies consider requests with cookies as being private and thus disable caching.

I'm not sure this is the correct fix here but it felt like the only place we can do this because it has to happen during or after `$session->save()`.

Looking for feedback first before we finish this with tests etc.

Regarding Symfony 3.4: Not sure how this is affected because there's not even a `SessionUtils` class so I'd prefer to leave that fix to somebody who feels more comfortable with that code base 😄

/cc @aschempp

Commits
-------

b22a7263b9 [HttpFoundation] Clear invalid session cookie
2019-08-09 09:08:28 +02:00
.composer Drop hirak/prestissimo 2016-05-12 07:44:15 -05:00
.github Merge branch '3.4' into 4.3 2019-07-29 18:04:53 +02:00
src/Symfony [HttpFoundation] Clear invalid session cookie 2019-08-09 09:08:17 +02:00
.appveyor.yml Merge branch '3.4' into 4.2 2019-04-12 17:32:33 +02:00
.editorconfig Update .editorconfig 2018-09-06 16:22:56 +02:00
.gitignore Run the phpunit-bridge from a PR 2019-08-02 17:46:19 +02:00
.php_cs.dist Merge branch '3.4' into 4.3 2019-08-05 15:52:12 +02:00
.travis.yml minor #33000 Fix deprecations on 4.3 (jderusse) 2019-08-08 14:05:37 +02:00
CHANGELOG-4.0.md Merge branch '3.4' into 4.1 2018-08-01 18:22:14 +02:00
CHANGELOG-4.1.md updated CHANGELOG for 4.1.10 2019-01-06 17:16:07 +01:00
CHANGELOG-4.2.md updated CHANGELOG for 4.2.10 2019-06-26 16:19:37 +02:00
CHANGELOG-4.3.md updated CHANGELOG for 4.3.3 2019-07-28 09:10:02 +02:00
CODE_OF_CONDUCT.md Added the Code of Conduct file 2018-10-10 03:13:30 -07:00
composer.json Merge branch '3.4' into 4.3 2019-08-07 10:30:22 +02:00
CONTRIBUTING.md Mention the community review guide 2016-12-18 22:02:35 +01:00
CONTRIBUTORS.md update CONTRIBUTORS for 3.4.30 2019-07-27 19:14:05 +02:00
LICENSE update year in license files 2019-01-01 14:45:19 +01:00
link Merge branch '3.4' into 4.2 2019-05-20 18:15:26 +02:00
phpunit bump phpunit-bridge cache-id 2019-08-06 08:41:45 +02:00
phpunit.xml.dist [Cache] Add optimized FileSystem & Redis TagAware Adapters 2019-04-24 07:47:35 +02:00
README.md Merge branch '2.8' into 3.4 2018-05-25 16:50:57 +02:00
UPGRADE-4.0.md Merge branch '3.4' into 4.2 2019-06-06 12:03:46 +02:00
UPGRADE-4.1.md Merge branch '4.0' into 4.1 2018-05-31 12:17:53 +02:00
UPGRADE-4.2.md [Validator] fix deprecation layer of ValidatorBuilder 2019-06-06 19:07:55 +02:00
UPGRADE-4.3.md Clarify deprecations for framework.templating 2019-07-23 09:11:32 +02:00
UPGRADE-5.0.md Clarify deprecations for framework.templating 2019-07-23 09:11:32 +02:00

Symfony is a PHP framework for web applications and a set of reusable PHP components. Symfony is used by thousands of web applications (including BlaBlaCar.com and Spotify.com) and most of the popular PHP projects (including Drupal and Magento).

Installation

Documentation

Community

Contributing

Symfony is an Open Source, community-driven project with thousands of contributors. Join them contributing code or contributing documentation.

Security Issues

If you discover a security vulnerability within Symfony, please follow our disclosure procedure.

About Us

Symfony development is sponsored by SensioLabs, led by the Symfony Core Team and supported by Symfony contributors.