Must-share information (formatted with Markdown):
- which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension) - Enterprise Edition- Version 8.9.6 (build 50800)
- how is SonarQube deployed: Deployed in Azure K8s using Helm
- what are you trying to achieve -
Wanted to clear the risk raised. SQL Injections threat is reported on SonarQube scan report by WAS scan team with below details. - CWE CWE-89
- OWASP A3 Injection
- WASC WASC-19 SQL INJECTION
Threat
SQL injection enables an attacker to modify the syntax of a SQL query in order to retrieve, corrupt, or delete data. This is accomplished by manipulating query
criteria in a manner that affects the query’s logic. The typical causes of this vulnerability are lack of input validation and insecure construction of the SQL query.
Queries created by concatenating strings with SQL syntax and user-supplied data are prone to this vulnerability. If any part of the string concatenation can be
modified, then the meaning of the query can be changed.
Impact
The scope of a SQL injection exploit varies greatly. If any SQL statement can be injected into the query, then the attacker has the equivalent access of a
database administrator. This access could lead to theft of data, malicious corruption of data, or deletion of data.
Solution
SQL injection vulnerabilities can be addressed in three areas: input validation, query creation, and database security.
All input received from the Web client should be validated for correct content. If a value’s type or content range is known beforehand, then stricter filters should be
applied. For example, an email address should be in a specific format and only contain characters that make it a valid address; or numeric fields like a U.S. zip
code should be limited to five digit values.
Prepared statements (also referred to as parameterized queries) provide strong protection from SQL injection. Prepared statements are precompiled SQL queries
whose parameters can be modified when the query is executed. Prepared statements enforce the logic of the query and will fail if the query cannot be compiled
correctly. Programming languages that support prepared statements provide specific functions for creating queries. These functions are more secure than string
concatenation for assigning user-supplied data to a query.
Stored procedures are precompiled queries that reside in the database. Like prepared statements, they also enforce separation of query data and logic. SQL
statements that call stored procedures should not be created via string concatenation, otherwise their security benefits are negated.
SQL injection exploits can be mitigated by the use of Access Control Lists or role-based access within the database. For example, a read-only account would
prevent an attacker from modifying data, but would not prevent the user f
- what have you tried so far to achieve this -
No straightforward solution finds so far on this issue.
Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!