SensioLabs closed multiple vulnerabilities in all supported versions of Symfony

    In particular, it is reported that the following versions are vulnerable: 2.7.0 - 2.7.37, 2.8.0 - 2.8.30, 3.2.0 -3.2.13, and 3.3.0 - 3.3.12. An interesting fact: in other versions, these vulnerabilities may also be present, but there are no fixes for them (due to the fact that fixes are only in supported versions).

    To fix vulnerabilities, you need to upgrade to versions 2.7.38, 2.8.31, 3.2.14, 3.3.13, 3.4-BETA5, or 4.0-BETA5.



    And a little more about the vulnerabilities themselves:

    1. CSRF protection does not use different tokens for HTTP and HTTPS


    Because of this, the token could undergo a MITM attack (the man in the middle) using HTTP, and the same token could be used in the context of HTTPS to carry out CSRF attacks.

    More details about the vulnerability: link

    2. Open Handler Redirect Vulnerability


    DefaultAuthenticationSuccessHandler or DefaultAuthenticationFailureHandler take the contents of the _target_path parameter and generate a redirect, but it does not check if the path itself is an absolute URL for an external domain, thereby opening a redirect vulnerability.

    The open redirect vulnerability is not too dangerous for a server with Symfony, but it can be used, for example, to install effective phishing attacks.

    More details about the vulnerability: link

    3. Going beyond the boundaries of paths in Intl bundle


    The Intl component includes various package readers that are used to read resources from the local file system. The read () methods of these classes use path and locale to determine the language (meaning working with multilingual applications) and the bundle to retrieve data.

    The value of the locale argument is usually extracted from untrusted user input (such as a URL parameter). An attacker can use this argument to navigate to arbitrary directories using a point-to-point-slash attack (../../).

    More details about the vulnerability: link

    4. Ability to issue a POST request as a downloadable file


    When the form is submitted by the user, the classes of the request processor of the Form component combine the POST data (known as the $ _POST array in simple PHP) and load the files (known as the $ _FILES array in simple PHP) into one array. This large array forms data, which is then attached to the form. At this point, there is no difference between the submitted POST data and the uploaded files.

    The user can send a processed HTTP request, where the FileType value is sent as normal POST data, which can be interpreted as the path to the files on the server side (for example, file: /// etc / passwd ). If the application does not perform any additional checks regarding the value passed to FileType, the contents of this file on the server may be attacked.

    More details about the vulnerability: link

    Afterword:


    Fortunately, starting with version 2.7, Symfony has an integrated analyzer for known vulnerabilities that, with a simple console command, checks all installed dependencies:

    bin/security-checker security:check

    In our case, the command was automatically executed when switching branches, because we became aware of vulnerabilities almost immediately, which helped to close them, in fact, faster than we read what vulnerabilities were discovered.

    If for some reason you cannot use this command in the console, you can always check your dependencies on the official website .

    Also popular now: