Withdrawn Advisory This advisory has been withdrawn because it is not a vulnerability in the Sylius framework. This link is maintained to preserve external references.

Original Description A rate limiting issue in Sylius v2.0.2 allows a remote attacker to perform unrestricted brute-force attacks on user accounts, significantly increasing the risk of account compromise and denial of service for legitimate users. The Supplier's position is that the Sylius core software is not intended to address brute-force attacks; instead, customers deploying a Sylius-based system are supposed to use "firewalls, rate-limiting middleware, or authentication providers" for that functionality.

sylius/sylius versions prior to 1.9.10, 1.10.11, and 1.11.2 are vulnerable to stored cross-site scripting (XSS) through SVG files. This vulnerability allows attackers to inject malicious scripts that can be executed in the context of the user's browser.

Sylius is an open source eCommerce platform. In versions prior to 1.9.10, 1.10.11, and 1.11.2, it is possible to upload an SVG file containing cross-site scripting (XSS) code in the admin panel. In order to perform a XSS attack, the file itself has to be open in a new card or loaded outside of the IMG tag. The problem applies both to the files opened on the admin panel and shop pages. The issue is fixed in versions 1.9.10, 1.10.11, and 1.11.2. As a workaround, require a library that adds on-upload file sanitization and overwrite the service before writing the file to the filesystem. The GitHub Security Advisory contains more specific information about the workaround.

Sylius is an open source eCommerce platform. Prior to versions 1.10.11 and 1.11.2, the reset password token was not set to null after the password was changed. The same token could be used several times, which could result in leak of the existing token and unauthorized password change. The issue is fixed in versions 1.10.11 and 1.11.2. As a workaround, overwrite the Sylius\Bundle\ApiBundle\CommandHandler\ResetPasswordHandler class with code provided by the maintainers and register it in a container. More information about this workaround is available in the GitHub Security Advisory.

Sylius is an open source eCommerce platform. Prior to versions 1.9.10, 1.10.11, and 1.11.2, any other user can view the data if browser tab remains unclosed after log out. The issue is fixed in versions 1.9.10, 1.10.11, and 1.11.2. A workaround is available. The application must strictly redirect to login page even browser back button is pressed. Another possibility is to set more strict cache policies for restricted content.

Sylius is an open source eCommerce platform. Prior to versions 1.9.10, 1.10.11, and 1.11.2, it is possible for a page controlled by an attacker to load the website within an iframe. This will enable a clickjacking attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. The issue is fixed in versions 1.9.10, 1.10.11, and 1.11.2. A workaround is available. Every response from app should have an X-Frame-Options header set to: sameorigin. To achieve that, add a new subscriber in the app.

Sylius is an Open Source eCommerce platform on top of Symfony. In versions of Sylius prior to 1.9.5 and 1.10.0-RC.1, part of the details (order ID, order number, items total, and token value) of all placed orders were exposed to unauthorized users. If exploited properly, a few additional information like the number of items in the cart and the date of the shipping may be fetched as well. This data seems to not be crucial nor is personal data, however, could be used for sociotechnical attacks or may expose a few details about shop condition to the third parties. The data possible to aggregate are the number of processed orders or their value in the moment of time. The problem has been patched at Sylius 1.9.5 and 1.10.0-RC.1. There are a few workarounds for the vulnerability. The first possible solution is to hide the problematic endpoints behind the firewall from not logged in users. This would put only the order list under the firewall and allow only authorized users to access it. Once a user is authorized, it will have access to theirs orders only. The second possible solution is to decorate the \Sylius\Bundle\ApiBundle\Doctrine\QueryCollectionExtension\OrdersByLoggedInUserExtension and throw Symfony\Component\Security\Core\Exception\AccessDeniedException if the class is executed for unauthorized user.

Impact The user may register in a shop by email mail@example.com, verify it, change it to the mail another@domain.com and stay verified and enabled. This may lead to having accounts addressed to totally different emails, that were verified. Note, that this way one is not able to take over any existing account (guest or normal one).

Patches Patch has been provided for Sylius 1.6.x and newer - 1.6.9, 1.7.9, 1.8.3. Versions older than 1.6 are not covered by our security support anymore.

Workarounds If for whatever reason you are not able to upgrade your application version, you may resolve this issue on your own by creating a custom event listener, which will listen to the sylius.customer.preupdate event. You can determine that email has been changed if customer email and user username are different. They are synchronized later on. Pay attention, to email changing behavior for administrators. You may need to skip this logic for them. In order to achieve this, you should either check master request path info, if it does not contain /admin prefix or adjust event triggered during customer update in the shop. You can find more information on how to customize the event here.

Acknowledgements

This security issue has been reported by Mircea Silviu (@decemvre), thanks a lot!

For more information

If you have any questions or comments about this advisory: Email us at security@sylius.com

Impact

Request parameters injected inside an expression evaluated by symfony/expression-language package haven't been sanitized properly. This allows the attacker to access any public service by manipulating that request parameter, allowing for Remote Code Execution.

The vulnerable versions include: <=1.3.13 || >=1.4.0 <=1.4.6 || >=1.5.0 <=1.5.1 || >=1.6.0 <=1.6.3.

Example

yaml foo: path: /foo/{id} defaults: sylius: repository: method: findSome arguments: entity: "expr:service('repository').find($id)"

In this case, $id can be prepared in a way that calls other services.

If you visit /foo/"~service('doctrine').getManager().getConnection().executeQuery("DELETE FROM TABLE")~", it will result in a following expression expr:service('repository').find(""~service('doctrine').getManager().getConnection().executeQuery("DELETE FROM TABLE")~""), which will execute a query on the currently connected database.

To find a vulnerability in your application, look for any routing definition that uses request parameters inside expression language.

Patches

This issue has been patched for versions 1.3.14, 1.4.7, 1.5.2 and 1.6.4. Versions prior to 1.3 were not patched.

Workarounds

The fix requires adding addslashes in ParametersParser::parseRequestValueExpression to sanitize user input before evaluating it using the expression language.

php - return isstring($variable) ? sprintf('"%s"', $variable) : $variable; + return isstring($variable) ? sprintf('"%s"', addslashes($variable)) : $variable;

Acknowledgements

This security issue has been reported by Craig Blanchette (@isometriks), thanks a lot!

For more information

If you have any questions or comments about this advisory: Email us at security@sylius.com

Impact

Request parameters injected inside an expression evaluated by symfony/expression-language package haven't been sanitized properly. This allows the attacker to access any public service by manipulating that request parameter, allowing for Remote Code Execution.

The vulnerable versions include: <=1.3.13 || >=1.4.0 <=1.4.6 || >=1.5.0 <=1.5.1 || >=1.6.0 <=1.6.3.

Example

yaml syliusgrid: grids: foo: fields: bar: options: baz: "expr:service('sylius.repository.product').find($id)"

In this case, $id can be prepared in a way that calls other services.

If you visit /route?id="~service('doctrine').getManager().getConnection().executeQuery("DELETE FROM TABLE")~", it will result in a following expression expr:service('repository').find(""~service('doctrine').getManager().getConnection().executeQuery("DELETE FROM TABLE")~""), which will execute a query on the currently connected database.

To find a vulnerability in your application, look for any routing definition that uses request parameters inside expression language.

Patches

This issue has been patched for versions 1.3.14, 1.4.7, 1.5.2 and 1.6.4. Versions prior to 1.3 were not patched.

Workarounds

The fix requires adding addslashes in OptionsParser::parseOptionExpression to sanitize user input before evaluating it using the expression language.

php - return isstring($variable) ? sprintf('"%s"', $variable) : $variable; + return isstring($variable) ? sprintf('"%s"', addslashes($variable)) : $variable;

Acknowledgements

This security issue has been reported by Craig Blanchette (@isometriks), thanks a lot!

For more information

If you have any questions or comments about this advisory: Email us at security@sylius.com

In affected versions of Sylius, exception messages from internal exceptions (like database exception) are wrapped by \Symfony\Component\Security\Core\Exception\AuthenticationServiceException and propagated through the system to UI. Therefore, some internal system information may leak and be visible to the customer. A validation message with the exception details will be presented to the user when one will try to log into the shop. This has been patched in versions 1.3.14, 1.4.10, 1.5.7, and 1.6.3.

An issue was discovered in Sylius products. Missing input sanitization in sylius/sylius 1.0.x through 1.0.18, 1.1.x through 1.1.17, 1.2.x through 1.2.16, 1.3.x through 1.3.11, and 1.4.x through 1.4.3 and sylius/grid 1.0.x through 1.0.18, 1.1.x through 1.1.18, 1.2.x through 1.2.17, 1.3.x through 1.3.12, 1.4.x through 1.4.4, and 1.5.0 allows an attacker (an admin in the sylius/sylius case) to perform XSS by injecting malicious code into a field displayed in a grid with the "string" field type. The contents are an object, with malicious code returned by the toString() method of that object.