SQL injection attacks take advantage of dynamically created SQL queries which use inadequately sanitized user input from web-based requests. By embedding SQL commands in user inputs, attackers can indirectly manipulate an SQL query issued by the web application to a database. Attackers can determine if an application is vulnerable, and can view, modify or delete application data by manipulating SQL queries dynamically. SQL injection attacks are simple to understand and attempt, and allow access to sensitive or even critical application data, making them attractive to attackers..
Successful attacks compromise sensitive application data, can manipulate or delete the SQL database, can deface websites, can open reverse shells, or may even access the underlying OS. Injection attacks can be combined with XSS attacks.
Successful blind SQL injection attacks merely detect a variation in behavior, whether timing or response, based on an attempted injection to determine whether an application is vulnerable to SQL injection attacks.
Readily available off-the-shelf free tools (e.g., Havij, splmap) allow novice users to successfully execute injection attacks. In addition, highly sophisticated tools exist which intensely probe applications for obscure vulnerabilities.
The following input data can contain SQL injection attacks:
- URL Parameters Name or Value
- FORM parameters Name or Value
- Request Headers
An attacker guesses that a web application uses the following SQL query to retrieve account details:
select accnt-detail from acct-master WHERE accnt=accntNumber
If accntNumber is a user input from an HTTP request, an attacker could make it:
5672' OR 'a'='a
and the resulting query would be
select accnt-detail from acct-master WHERE accnt='5672' OR 'a'='a'
Since the above query always evaluates to true, every database row matches ('a'='a' is always TRUE) and the resulting query returns all accnt-detail entries from the database.
For SQL databases which allow semi-colon separated SQL commands to immediately execute, input data containing arbitrary SQL commands could execute.
SQL injection can be prevented by secure coding, either by using prepared (parametrized) statements, or by properly escaping and sanitizing inputs. Either method can prevent input data which contains commands from executing. When using legacy or third party code, or for tightly coupled interfaces where sanitizing inputs may not be possible, you can rely on Barracuda Web Application Firewall rule sets to inspect and block SQL injection across all input vectors. Inputs are first normalized to defeat obfuscation, such as encoding techniques (e.g. UTF8) or SQL specific techniques (e.g. embedded SQL comments to obfuscate the actual SQL query).
OWASP Top 10, PCI-DSS
<a href="http://cwe.mitre.org/data/definitions/89.html" target="_blank" class="external" id="2faafad7">CWE 89</a>,<a href="https://www.owasp.org/index.php/SQL_Injection" target="_blank" class="external" id="2faafad7"> OWASP</a>, <a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection" target="_blank" class="external" id="2faafad7">WASC</a>