What is SQL injection
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, user lists or private customer details.
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.
When calculating the potential cost of a SQLI, it’s important to consider the loss of customer trust should personal information such as phone numbers, addresses and credit card details be stolen.
While this vector can be used to attack any SQL database, websites are the most frequent targets.
What are SQL queries
SQL is a standardized language used to access and manipulate databases to build customizable data views for each user. SQL queries are used to execute commands, such as data retrieval, updates and record removal. Different SQL elements implement these tasks, e.g., queries using the SELECT statement to retrieve data, based on user-provided parameters.
A typical eStore’s SQL database query may look like the following:
SELECT ItemName, ItemDescription FROM Item WHERE ItemNumber = ItemNumber
From this, the web application builds a string query that is sent to the database as a single SQL statement:
sql_query= " SELECT ItemName, ItemDescription FROM Item WHERE ItemNumber = " & Request.QueryString("ItemID")
A user-provided input http://www.estore.com/items/items.asp?itemid=999 can then generates the following SQL query:
SELECT ItemName, ItemDescription FROM Item WHERE ItemNumber = 999
As you can gather from the syntax, this query provides the name and description for item number 999.
SQL injection example
An attacker wishing to execute SQL injection manipulates a standard SQL query to exploit non-validated input vulnerabilities in a database. There are many ways that this attack vector can be executed, several of which will be shown here to provide you with a general idea about how SQLI works.
For example, the above-mentioned input, which pulls information for a specific product, can be altered to read http://www.estore.com/items/items.asp?itemid=999 or 1=1.
As a result, the corresponding SQL query looks like this:
SELECT ItemName, ItemDescription FROM Items WHERE ItemNumber = 999 OR 1=1
And since the statement 1 = 1 is always true, the query returns all of the product names and descriptions in the database, even those thay you may not be eligible to access.
Attackers are also able to take advantage of incorrectly filtered characters to alter SQL commands, including using a semicolon to separate two fields.
For example, this input http://www.estore.com/items/iteams.asp?itemid=999; DROP TABLE Users would generate the following SQL query:
SELECT ItemName, ItemDescription FROM Items WHERE ItemNumber = 999; DROP TABLE USERS
As a result, the entire user database could be deleted.
Another way SQL queries can be manipulated is with a UNION SELECT statement. This combines two unrelated SELECT queries to retrieve data from different database tables.
For example, the input http://www.estore.com/items/items.asp?itemid=999 UNION SELECT user-name, password FROM USERS produces the following SQL query:
SELECT ItemName, ItemDescription FROM Items WHERE ItemID = '999' UNION SELECT Username, Password FROM Users;
Using the UNION SELECT statement, this query combines the request for item 999’s name and description with another that pulls names and passwords for every user in the database.
SQLI prevention and mitigation
There are several effective ways to prevent SQLI attacks from taking place, as well as protecting against them, should they occur.
The first step is input validation (a.k.a. sanitization), which is the practice of writing code that can identify illegitimate user inputs.
While input validation should always be considered best practice, it is rarely a foolproof solution. The reality is that, in most cases, it is simply not feasible to map out all legal and illegal inputs—at least not without causing a large amount of false positives, which interfere with user experience and an application’s functionality.
For this reason, a web application firewall (WAF) is commonly employed to filter out SQLI, as well as other online threats. To do so, a WAF typically relies on a large, and constantly updated, list of meticulously crafted signatures that allow it to surgically weed out malicious SQL queries. Usually, such a list holds signatures to address specific attack vectors, and is regularly patched to introduce blocking rules for newly discovered vulnerabilities.
Modern web application firewalls are also often integrated with other security solutions. From these, a WAF can receive additional information that further augments its security capabilities.
For example, a web application firewall that encounters a suspicious, but not outright malicious, input may be cross-verify it with IP data before deciding to block the request. It only blocks the input if the IP itself has a bad reputational history.
Imperva cloud-based WAF uses signature recognition, IP reputation and other security methodologies to identify and block SQL injections, with a minimal amount of false positives. The WAF’s capabilities are augmented by IncapRules—a custom security rule engine that enables granular customization of default security settings and the creation of additional case-specific security policies.
Our WAF also employs crowdsourcing techniques that ensure that new threats targeting any user are immediately propagated across the entire user-base. This enables rapid response to newly disclosed vulnerability and zero-day threats.