The class of vulnerabilities known as SQL injection continues to present an extremely high risk in the current network threat landscape. SQL injection has been ranked as one of the top risks on the MITRE Common Weakness Enumeration (CWE)/SANS Top 25 Most Dangerous Software Errors list. https://www.sans.org/top25-software-errors Exploitation of these vulnerabilities has been implicated in many recent high-profile intrusions.
Although there is an abundance of good literature in the community about how to prevent SQL injection vulnerabilities, much of this documentation is geared toward web application developers. This advice is of limited benefit to IT administrators who are merely responsible for the operation of targeted web applications.
The following information will provide concrete guidance about using open source tools and techniques to independently identify common SQL injection vulnerabilities, mimicking the approaches of attackers at large. We highlight testing tools and illustrate the critical results of testing.
SQL Injection
Causes Simply stated, SQL injection vulnerabilities are caused by software applications that accept data from an untrusted source (internet users), fail to properly validate and sanitize the data, and subsequently use that data to dynamically construct an SQL query to the database backing that application. For example, imagine a simple application that takes inputs of a username and password. It may ultimately process this input in an SQL statement of the form string query = “SELECT * FROM users WHERE username = “'” + username + “' AND password = ‘” + password + “'"; Since this query is constructed by concatenating an input string directly from the user, the query behaves correctly only if password does not contain a single-quote character. If the user enters “john” as the username and “example’ OR ‘a’=‘a as the password, the resulting query becomes SELECT * FROM users WHERE username = ‘john’ AND password = ‘example’ OR ‘a’=‘a’;
The “OR ‘a’=‘a’ clause always evaluates to true and the intended authentication check is bypassed as a result.
While any application that incorporates SQL can suffer from these vulnerabilities, they are most common in web-based applications. One reason for the persistence of these problems is that their underlying causes can be found in almost any web application, regardless of implementation technology, web framework, programming language, or popularity. This class of vulnerabilities is also particularly severe in that merely identifying them is tantamount to full exploitation. Indeed, this is what attackers are doing on an internet scale.
SQL Injection Impacts
Many of the high-profile intrusions in which SQL injection has been implicated have received attention because of the breach of confidentiality in the data stored in the compromised databases. This loss of confidentiality and the resulting financial costs for recovery, downtime, regulatory penalties, and negative publicity represent the primary immediate consequences of a successful compromise. However, even sites hosting applications that do not use sensitive financial or customer information are at risk as the database’s integrity can be compromised. Exploitation of SQL injection vulnerabilities may also allow an attacker to take advantage of persistent storage and dynamic page content generation to include malicious code in the compromised site. As a result, visitors to that site could be tricked into installing malicious code or redirected to a malicious site that exploits other vulnerabilities in their systems [2][3]. In many cases, exploitation of SQL injection vulnerabilities can also result in a total compromise of the database servers, allowing these systems to be used as intermediaries in attacks on third-party sites.
SQL Injection Attack Vectors
It is important to recognize that any data that is passed from the user to the vulnerable web application and then processed by the supporting database represents a potential attack vector for SQL injection. In practice, the two most common attack vectors are form data supplied through HTTP GET and through HTTP POST. We will demonstrate these attack vectors in the examples below. Other possible attack vectors include HTTP cookie data and the HTTP User-Agent and Referer header values. Some SQL injection vulnerabilities may only be exploitable via authenticated unprivileged user accounts, depending upon where the application fails to sanitize the input. Sites and applications that allow users to create new accounts on the fly are at additional risk as a result.
SQL Injection : Detection Heuristics
Automatic detection of SQL injection vulnerabilities relies on heuristics of how the target application behaves (or rather misbehaves) in response to specially crafted queries. The techniques are sometimes categorized into the following types:
- Boolean-based blind SQL injection (sometimes referred to as inferential SQL injection): Multiple valid statements that evaluate to true and false are supplied in the affected parameter in the HTTP request. By comparing the response page between both conditions, the tool can infer whether or not the injection was successful.
- Time-based blind SQL injection (sometimes referred to as full blind SQL injection): Valid SQL statements are supplied in the affected parameter in the HTTP request that cause the database to pause for a specific period of time. By comparing the response times between normal requests and variously timed injected requests, a tool can determine whether execution of the SQL statement was successful.
- Error-based SQL injection: Invalid SQL statements are supplied to the affected parameter in the HTTP request. The tool then monitors the HTTP responses for error messages that are known to have originated at the database server. Most tools employ a combination of these techniques and some variations in order to achieve better detection and exploitation success.
Learn more