CVE-2022-24895: Possible CSRF token fixation

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

php-symfony2-Validator has loss of information during serialization

Ability to enable/disable object support in YAML parsing and dumping

Ability to enable/disable PHP parsing in Yaml::parse()

Description

The Request class improperly interprets some PATHINFO in a way that leads to representing some URLs with a path that doesn't start with a /. This can allow bypassing some access control rules that are built with this /-prefix assumption.

Resolution

The Request class now ensures that URL paths always start with a /.

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

Credits

We would like to thank Andrew Atkinson for discovering the issue, Chris Smith for reporting it and Nicolas Grekas for providing the fix.

Code execution vulnerability via the "internal" routes

Applications with ESI support (and SSI support as of Symfony 2.6) enabled and using the Symfony built-in reverse proxy (the Symfony\Component\HttpKernel\HttpCache class) are vulnerable to PHP code injection; a malicious user can inject PHP code that will be executed by the server.

HttpCache uses eval() to execute files in its cache when they contain ESI tags (and only when ESI is enabled). The vulnerability comes from the fact that PHP allows contents of <script language="php"> tags to be executed (and this kind of PHP tags is always available regardless of the configuration), but there were not escaped before the evaluation.

A possible exploit comes from websites also vulnerable to Cross-Site Scripting as an attacker can successfully conduct a PHP code injection attack by passing such a tag in a user submitted variable (for which proper output escaping was not applied).

On the Symfony 2.0.x version, there's a security issue that allows access to routes protected by a firewall even when the user is not logged in.

Both the Routing component and the Security component uses the path returned by getPathInfo() to match a Request. The getPathInfo() returns a decoded path, but the Routing component (Symfony\Component\Routing\Matcher\UrlMatcher) decodes the path a second time; whereas the Security component, Symfony\Component\HttpFoundation\RequestMatcher, does not.

This difference causes Symfony 2.0 to be vulnerable to double encoding attacks.

Request::getHost() poisoning

Description

Some Twig filters in CodeExtension use "issafe=html" but don't actually ensure their input is safe.

Resolution

Symfony now escapes the output of the affected filters.

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

Credits

We would like to thank Pierre Rudloff for reporting the issue and to Nicolas Grekas for providing the fix.

Possible DOS attack with long user-submitted passwords