We use cookies on our website to ensure we provide you with the best experience on our website. By using our website, you agree to the use of cookies for analytics and personalized content.This website uses cookies. More Information
It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Web Application Firewall

SQL Injection Attack

  • Last updated on

Description

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..

Effects

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.

Methods

The following input data can contain SQL injection attacks:

  • URL Parameters Name or Value
  • FORM parameters Name or Value
  • Request Headers
  • Cookies

Example

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.

Prevention

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).

Tags

OWASP Top 10, PCI-DSS

See Also

<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>
Last updated on