Context
SQL injection, also known as SQLI, is a common attack vector that uses malicious SQL code for backend database manipulation to access information that was not intended to be displayed. This information may include any number of items, including sensitive company data such as username and passwords, personal user details or even customers private data such as credit cards information.
The impact SQL injection can have on a business is far-reaching. A successful attack may result in the unauthorized viewing of user lists, the deletion of entire tables and, in certain cases, the attacker gaining administrative rights to a database, all of which are highly detrimental to a business.
Consequences
Cyber-terms
Direct impact on the confidentiality of the data stored in the database.
All the data stored in the database is compromised and, depending on the configuration, further access can be obtained (such as code execution on the server hosting the database). As the exploitation of the vulnerability does not need authentication to the application (our scanner does not support authentication), its impact is critical.
Managerial terms
Exploitation of the vulnerability leads to indirect financiary losses by impacting the confidentiality of stored data, which may results in public outcomes and loss of trust.
Access to all the services that rely on the impacted database will potentialy be unavailable until the attack is mitigated which may result in important downtimes.
Remediation
API with Parameterized Statements
Switching from taking direct input in a web app to using a safe API is probably the safest way to deal with SQL injection.
This will usually avoid calling upon the SQL interpreter and will instead use premade calls instead.
Creating a parameterized API is the best method for mitigating SQL injection attacks.
Character Escaping
If an API is not available, your web applications should be able to escape special characters (i.e. all the characters having an impact on the syntax of SQL languages)..
This should be considered a last line of defense, since character escaping is not entirely bulletproof.
Alternatively, the web application itself can attempt to escape queries, but depending on how requests are handled, it becomes even more difficult to escape.
The best way to defend against injection remains parametrized API calls, since it operates on the principle of white listing, not black-listing commands and calls.