CVE-2019-10910: Check service IDs are valid
CVE-2022-23601: CSRF token missing in forms
CVE-2022-24895: Possible CSRF token fixation
CVE-2022-24894: Prevent storing cookie headers in HttpCache
End of life: 1/31/2025, End of support: 1/31/2025, Latest version: 7.1.11
End of life: 1/31/2025, End of support: 1/31/2025, Latest version: 7.1.11
Description
SessionStrategyListener does not always migrate the session after a successful login. It only migrate the session when the logged-in user identifier changes. In some use cases, the user identifier doesn't change between the verification phase and the successful login, while the token itself changes from one type (partially-authenticated) to another (fully-authenticated). When this happens, the session id should be regenerated to prevent possible session fixations.
Resolution
Symfony now checks the type of the token in addition to the user identifier before deciding whether the session id should be regenerated.
The patch for this issue is available here for branch 5.4.
Credits
We would like to thank Robert Meijers for reporting the issue and providing the fix.
Description
The error message in WebhookController returns unescaped user-submitted input.
Resolution
WebhookController now doesn't return any user-submitted input in its response.
The patch for this issue is available here for branch 6.3.
Credits
We would like to thank Maxime Aknin for reporting the issue and to Nicolas Grekas for providing the fix.
CVE-2021-41270: Prevent CSV Injection via formulas
CVE-2021-41267: Webcache Poisoning via X-Forwarded-Prefix and sub-request
CVE-2021-41268: Remember me cookie persistance after password changes
Impact Under certain circumstances, an attacker could successfully submit an entity id for an EntityType that is not part of the valid choices.
Affected applications are any that use:
A custom querybuilder option to limit the valid results; AND An EntityType with 'autocomplete' => true or a custom AsEntityAutocompleteField.
Under this circumstance, if an id is submitted, it is accepted even if the matching record would not be returned by the custom query built with querybuilder.
Patches
The problem has been fixed in symfony/ux-autocomplete version 2.11.2.
Workarounds Upgrade to version 2.11.2 or greater of symfony/ux-autocomplete or perform extra validation after submit to verify the selected option is valid.
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.
An information disclosure flaw was found in the way Symfony, a open-source PHP web framework, sanitized certain HTTP POST request values. A remote attacker could use this flaw to obtain (unauthorized) read access to arbitrary system files, readable with the privileges of the web server process.
References: [1] http://symfony.com/blog/security-release-symfony-1-4-20-released [2] https://bugs.gentoo.org/showbug.cgi?id=444696
Relevant upstream patch: [3] http://trac.symfony-project.org/changeset/33598
Possible DOS attack with long user-submitted passwords
Request::getHost() poisoning
php-symfony2-Validator has loss of information during serialization
CVE-2015-8125: Potential Remote Timing Attack Vulnerability in Security Remember-Me Service
A session fixation vulnerability within the "Remember Me" login feature allows an attacker to impersonate the victim towards the web application if the session id value was previously known to the attacker. This issue has been fixed in Symfony 2.3.35, 2.6.12, and 2.7.7. Note that no fixes are provided for Symfony 2.4 and 2.5 as they are not maintained anymore. Symfony 2.8 and 3.0 haven't been released yet and the fix will be included in their first stable releases.
CVE-2015-4050: ESI unauthorized access
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).
CVE-2016-4423: Large username storage in session
CVE-2016-1902: SecureRandom's fallback not secure when OpenSSL fails
DISPUTED The debug handler in Symfony before v2.7.33, 2.8.x before v2.8.26, 3.x before v3.2.13, and 3.3.x before v3.3.6 has XSS via an array key during exception pretty printing in ExceptionHandler.php, as demonstrated by a /debugbar/open?op=get URI. NOTE: the vendor's position is that this is not a vulnerability because the debug tools are not intended for production use. NOTE: the Symfony Debug component is used by Laravel Debugbar.
An issue was discovered in Symfony before 2.7.38, 2.8.31, 3.2.14, 3.3.13, 3.4-BETA5, and 4.0-BETA5. The current implementation of CSRF protection in Symfony (Version >=2) does not use different tokens for HTTP and HTTPS; therefore the token is subject to MITM attacks on HTTP and can then be used in an HTTPS context to do CSRF attacks.
An issue was discovered in Symfony 2.7.x before 2.7.38, 2.8.x before 2.8.31, 3.2.x before 3.2.14, and 3.3.x before 3.3.13. DefaultAuthenticationSuccessHandler or DefaultAuthenticationFailureHandler takes the content of the targetpath parameter and generates a redirect response, but no check is performed on the path, which could be an absolute URL to an external domain. This Open redirect vulnerability can be exploited for example to mount effective phishing attacks.
An issue was discovered in Symfony before 2.7.38, 2.8.31, 3.2.14, 3.3.13, 3.4-BETA5, and 4.0-BETA5. The Intl component includes various bundle readers that are used to read resource bundles from the local filesystem. The read() methods of these classes use a path and a locale to determine the language bundle to retrieve. The locale argument value is commonly retrieved from untrusted user input (like a URL parameter). An attacker can use this argument to navigate to arbitrary directories via the dot-dot-slash attack, aka Directory Traversal.
An open redirect was discovered in Symfony 2.7.x before 2.7.50, 2.8.x before 2.8.49, 3.x before 3.4.20, 4.0.x before 4.0.15, 4.1.x before 4.1.9 and 4.2.x before 4.2.1. By using backslashes in the failurepath input field of login forms, an attacker can work around the redirection target restrictions and effectively redirect the user to any domain after login.
An issue was discovered in Symfony 2.7.x before 2.7.50, 2.8.x before 2.8.49, 3.x before 3.4.20, 4.0.x before 4.0.15, 4.1.x before 4.1.9, and 4.2.x before 4.2.1. When using the scalar type hint string in a setter method (e.g. setName(string $name)) of a class that's the dataclass of a form, and when a file upload is submitted to the corresponding field instead of a normal text input, then UploadedFile::toString() is called which will then return and disclose the path of the uploaded file. If combined with a local file inclusion issue in certain circumstances this could escalate it to a Remote Code Execution.
An issue was discovered in Http Foundation in Symfony 2.7.0 through 2.7.48, 2.8.0 through 2.8.43, 3.3.0 through 3.3.17, 3.4.0 through 3.4.13, 4.0.0 through 4.0.13, and 4.1.0 through 4.1.2. It arises from support for a (legacy) IIS header that lets users override the path in the request URL via the X-Original-URL or X-Rewrite-URL HTTP request header. These headers are designed for IIS support, but it's not verified that the server is in fact running IIS, which means anybody who can send these requests to an application can trigger this. This affects \Symfony\Component\HttpFoundation\Request::prepareRequestUri() where X-Original-URL and XREWRITEURL are both used. The fix drops support for these methods so that they cannot be used as attack vectors such as web cache poisoning.