Summary
The Archery project contains multiple SQL injection vulnerabilities, that may allow an attacker to query the connected databases.
Product
Archery
Tested Version
v1.9.0
Details
SQL injection exists in the project due to unsafe user input being concatenated with a SQL query, that is passed to methods executing a query in a database. All identified issues exist due to the controller files in folder sql
taking user input and not sanitizing it, which later is passed to execution. Since the controller methods are connected to and allows querying all the databases that are connected to Archery, then all databases making queries with concatenated input will be affected. In this way, one vulnerable endpoint allows for exploiting several databases. To exploit most of these SQL injections, knowledge of the exploited instance name that is defined in Archery, is needed.
Issue 3: SQL injection in sql_api/api_workflow.py
endpoint ExecuteCheck
post
method passing unsafe input to sql/engines/oracle.py
explain_check
method (GHSL-2022-103
)
User input coming from the db_name
parameter value in the api_workflow.py
ExecuteCheck
post
endpoint is passed through oracle.py
execute_check
method and to the explain_check
method for execution on line 574.
Remediation
Escape the variables accepting user input in sql_api/api_workflow.py
ExecuteCheck
post
endpoint that is db_name
and full_sql
by using f.ex. MySQLdb.escape(). This solution is easier to implement and will fix the issues in all SQL engines at once. Using this solution, it would fix the both GHSL-2022-102
and GHSL-2022-103
vulnerabilities.
Impact
All of the issues may lead to Information Disclosure
.
General remediation advice
To fix each of the issues, the best practice would be to escape the user input (as presented in Remediation
section of each of the issues) or use prepared statements when executing SQL queries. Using placeholders in cursor.execute() will automatically escape the passed values. See Django documentation around executing custom SQL directly and Connections and cursors.
Generally, it is best to use prepared statements rather, but for Archery's codebase it would be much easier to fix the issues by escaping user input, which is sufficient protection. Please consider also escaping all other variables which accept input from the user, particularly the ones from GET or POST requests.
For more information on preventing SQL injection see SQL Injection Prevention Cheat Sheet - Primary Defenses
Credit
These issues were discovered and reported by GHSL team member @sylwia-budzynska (Sylwia Budzynska).
Disclosure Policy
This report is subject to our coordinated disclosure policy.
Summary
The Archery project contains multiple SQL injection vulnerabilities, that may allow an attacker to query the connected databases.
Product
Archery
Tested Version
v1.9.0
Details
SQL injection exists in the project due to unsafe user input being concatenated with a SQL query, that is passed to methods executing a query in a database. All identified issues exist due to the controller files in folder
sql
taking user input and not sanitizing it, which later is passed to execution. Since the controller methods are connected to and allows querying all the databases that are connected to Archery, then all databases making queries with concatenated input will be affected. In this way, one vulnerable endpoint allows for exploiting several databases. To exploit most of these SQL injections, knowledge of the exploited instance name that is defined in Archery, is needed.Issue 3: SQL injection in
sql_api/api_workflow.py
endpointExecuteCheck
post
method passing unsafe input tosql/engines/oracle.py
explain_check
method (GHSL-2022-103
)User input coming from the
db_name
parameter value in theapi_workflow.py
ExecuteCheck
post
endpoint is passed throughoracle.py
execute_check
method and to theexplain_check
method for execution on line 574.Remediation
Escape the variables accepting user input in
sql_api/api_workflow.py
ExecuteCheck
post
endpoint that isdb_name
andfull_sql
by using f.ex. MySQLdb.escape(). This solution is easier to implement and will fix the issues in all SQL engines at once. Using this solution, it would fix the bothGHSL-2022-102
andGHSL-2022-103
vulnerabilities.Impact
All of the issues may lead to
Information Disclosure
.General remediation advice
To fix each of the issues, the best practice would be to escape the user input (as presented in
Remediation
section of each of the issues) or use prepared statements when executing SQL queries. Using placeholders in cursor.execute() will automatically escape the passed values. See Django documentation around executing custom SQL directly and Connections and cursors.Generally, it is best to use prepared statements rather, but for Archery's codebase it would be much easier to fix the issues by escaping user input, which is sufficient protection. Please consider also escaping all other variables which accept input from the user, particularly the ones from GET or POST requests.
For more information on preventing SQL injection see SQL Injection Prevention Cheat Sheet - Primary Defenses
Credit
These issues were discovered and reported by GHSL team member @sylwia-budzynska (Sylwia Budzynska).
Disclosure Policy
This report is subject to our coordinated disclosure policy.