CVE-2022-24894: Prevent storing cookie headers in HttpCache

February 1, 2023 · Published by Avatar of Fabien Potencier Fabien Potencier

Affected versions

Symfony versions >=2.0.0, <4.4.50, >= 5.0.0, < 5.4.20, >= 6.0.0, < 6.0.20, >= 6.1.0, < 6.1.12, and >= 6.2.0, < 6.2.6 of the Symfony Security Bundle are affected by this security issue.

The issue has been fixed in Symfony 4.4.50, 5.4.20, 6.0.20, 6.1.12, and 6.2.6. All other versions are not maintained anymore.

Description

The Symfony HTTP cache system acts as a reverse proxy: it caches HTTP responses (including headers) and returns them to clients.

In a recent AbstractSessionListener change, the response might now contain a Set-Cookie header. If the Symfony HTTP cache system is enabled, this header might be stored and returned to some other clients. An attacker can use this vulnerability to retrieve the victim's session.

Resolution

The HttpStore constructor now takes a parameter containing a list of private headers that are removed from the HTTP response headers. The default value for this parameter is Set-Cookie, but it can be overridden or extended by the application.

The patch for this issue is available here for branch 4.4.

Credits

We would like to thank Soner Sayakci for reporting the issue and Nicolas Grekas for fixing it.

Published in #Security Advisories

Have found a security issue in Symfony? Send the details to security [at] symfony.com and don't disclose it publicly until we can provide a fix for it.

Manage your notification preferences to receive an email as soon as a Symfony security release is published.

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Avatar of Guillaume Lajarige
Guillaume Lajarige said on Feb 1, 2023
"Symfony versions >=2.0.0, = 5.0.0, < 5.4.20, >= 6.0.0, < 6.0.20, >= 6.1.0, < 6.1.12, and >= 6.2.0, < 6.2.6 of the Symfony Security Bundle are affected by this security issue."

Does that mean that the 3.x branch was not affected?
Avatar of Matthieu Gostiaux
Matthieu Gostiaux Certified said on Feb 2, 2023
When i see >=2.0.0,
Avatar of Matthieu Gostiaux
Matthieu Gostiaux Certified said on Feb 2, 2023
Looks like my previous comment failed, was saying to me every 3.x versions are concerned.
Avatar of Olivier
Olivier said on Feb 7, 2023
For the record OWASP dependency-check PHP experimental option do not detect this vulnerablity. It could nice to help their team to release a stable version of this option, since it's a wildly used security tool?
Avatar of Guillaume Lajarige
Guillaume Lajarige said on Feb 22, 2023
Thanks Matthieu, indeed I should have read it that way.

On another topic, tags of Symfony sub repos have not been made yet, even though packagist.org referes them. Is that something overlooked?

symfony/dotenv: v5.4.20
symfony/framework-bundle: v5.4.20
symfony/http-foundation: v5.4.20
symfony/http-kernel: v5.4.20
symfony/twig-bundle: v5.4.20
symfony/workflow: v5.4.20
symfony/yaml: v5.4.20
...
Avatar of thomas da silva
thomas da silva said on Mar 30, 2023
Hello, I don’t understand how to fix this mistake. I don’t understand how to fix this mistake.
I have it when I run the symfony check:security command.
I don’t often work with symfony so I don’t know all the manipulation.
Do I need to update this package to the version 4.4 ? I try this but I have this error 'Your requirements could not be resolved to an installable set of packages.' because I have others packages.
Thank you

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.