Package Instance

Unrestricted Upload of File with Dangerous Type
When using the scalar type hint `string` in a setter method (e.g. `setName(string$name)`) of a class that's the `data_class` 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.

Prevent user enumeration using Guard or the new Authenticator-based Security
Description
-----------

The ability to enumerate users was possible without relevant permissions due to different exception messages depending on whether the user existed or not. It was also possible to enumerate users by using a timing attack, by comparing time elapsed when authenticating an existing user and authenticating a non-existing user.

Resolution
----------

We now ensure that 403s are returned whether the user exists or not if the password is invalid or if the user does not exist.

The patch for this issue is available [here](https://github.com/symfony/symfony/commit/2a581d22cc621b33d5464ed65c4bc2057f72f011) for branch 3.4.

Credits
-------

I would like to thank James Isaac and Mathias Brodala for reporting the issue and Robin Chalas for fixing the issue.

Attacker can read all files content on the server
When a form is submitted by the user, the request handler classes of the Form component merge POST data (known as the `$_POST` array in plain PHP) and uploaded files data (known as the `$_FILES` array in plain PHP) into one array. This big array forms the data that are then bound to the form. At this stage there is no difference anymore between submitted POST data and uploaded files. A user can send a crafted HTTP request where the value of a `FileType` is sent as normal `POST` data that could be interpreted as a locale file path on the server-side (for example, `file:///etc/passwd`). If the application did not perform any additional checks about the value submitted to the `FileType`, the contents of the given file on the server could have been exposed to the attacker.

Cross-Site Request Forgery (CSRF)
Symfony is a PHP framework for web and console applications and a set of reusable PHP components. The Symfony form component provides a CSRF protection mechanism by using a random token injected in the form and using the session to store and control the token submitted by the user. When using the FrameworkBundle, this protection can be enabled or disabled with the configuration. If the configuration is not specified, by default, the mechanism is enabled as long as the session is enabled. In a recent change in the way the configuration is loaded, the default behavior has been dropped and, as a result, the CSRF protection is not enabled in form when not explicitly enabled, which makes the application sensible to CSRF attacks. This issue has been resolved in the patch versions listed and users are advised to update. There are no known workarounds for this issue.

Duplicate
This advisory duplicates another.