SQL Injection: Techniques and Exploitation Methods
SQL injection (SQLi) occurs when an attacker can interfere with the queries that an application makes to its database. While the root cause—improper handling of user input—remains consistent, the methods used to exploit this vulnerability vary significantly depending on how the application responds to malicious input.
Key Facts
- Root Cause: All SQL injections stem from the same fundamental flaw in how user input is integrated into SQL statements.
- Direct Output: Some attacks allow attackers to see database results immediately on the screen.
- Blind SQLi: Used when the application does not return direct data but changes its behavior based on logical queries.
- Second-Order SQLi: Occurs when malicious data is stored first and executed later by a different part of the application.
- Prevention: Uniform security across all SQL processing, regardless of the data source, is essential for protection.
Direct Output and Action Exploitation
The most straightforward form of SQL injection happens when an application takes user input and concatenates it directly into a SQL string. For example, consider a program that uses the following assignment:
var statement = "SELECT * FROM users WHERE name = '" + userName + "'" ;
If a malicious user provides a crafted input for userName, they can alter the query's logic. By using a statement like ' OR '1'='1, the resulting query becomes SELECT * FROM users WHERE name = '' OR '1'='1'. Because '1'='1' is always true, the database may return every record in the users table, potentially bypassing authentication procedures.
[ไม่มีภาพประกอบ]
Attackers may also use SQL comments to block the remainder of the original query. In more severe cases, if the API allows multiple statements, an attacker could execute entirely separate commands. For instance, an input like a ' ; DROP TABLE users ; SELECT * FROM userinfo WHERE 't' = ' t could delete the users table while simultaneously extracting data from a different table called userinfo.
It is important to note that some APIs, such as PHP's mysql_query(), prohibit multiple statements in a single call for security reasons. While this prevents the injection of entirely new queries, it does not stop an attacker from modifying the existing one.
Blind SQL Injection
Blind SQL injection is employed when the web application is vulnerable, but the results of the injection are not visible to the attacker. Instead of seeing data on the page, the attacker observes how the page responds to different logical statements.
Historically, this method was time-intensive because attackers had to recover data bit by bit through numerous requests. However, modern advancements and automation tools have made this process more efficient, allowing for the extraction of multiple bits per request.
Conditional Responses
One common blind technique involves forcing the database to evaluate a logical statement that results in a visible change on the application screen. For example, a book review site might use a URL like https://books.example.com/review?id=5 to run a query against a bookreviews table.
An attacker can test for vulnerability by comparing two URLs:
.../review?id=5 ' OR ' 1 '=' 1(which should load the review normally).../review?id=5 ' AND ' 1 '=' 2(which should return a blank or error page)
If the page responds differently to these two inputs, the site is likely vulnerable. The attacker can then use more complex queries to glean specific information, such as the MySQL version, by using functions like substring() and INSTR() to check if the version number matches a specific digit.
Second-Order SQL Injection
Second-order SQL injection is a more subtle attack. It occurs when an application properly secures immediate user input but fails to apply the same rigor to data already stored in the system. In this scenario, the malicious SQL statement is safely stored in the database first. The exploit triggers later when a different part of the application retrieves that stored data and uses it in an unprotected query.
Because this attack relies on how data is used downstream, automated security scanners often struggle to detect it, frequently requiring manual testing to uncover the vulnerability.
| Injection Type | Visibility of Data | Execution Timing | Detection Difficulty |
|---|---|---|---|
| Direct Output | High (Directly on page) | Immediate | Low |
| Blind SQLi | Low (Inferred via behavior) | Immediate | Medium |
| Second-Order | Variable | Delayed | High |
Frequently Asked Questions
What is the main cause of all SQL injection attacks?
The root cause is the improper handling of user-supplied data, which allows it to be interpreted as part of a SQL command rather than as simple data.
How does Blind SQL injection differ from standard SQL injection?
Unlike standard SQL injection, where the database output is displayed on the page, Blind SQL injection requires the attacker to infer data based on the application's response (such as a page loading or an error appearing) to logical true/false statements.
Can PHP's mysql_query() prevent all SQL injections?
No. While mysql_query() prevents the execution of multiple statements in one call (stopping attackers from adding entirely new queries like DROP TABLE), it does not prevent attackers from modifying the logic of the existing query.
Why is second-order SQL injection harder to detect?
It is harder to detect because the malicious payload is not executed immediately upon input. Since the vulnerability exists in the way stored data is later used, automated scanners often miss the connection between the initial input and the eventual execution.
How can developers protect against second-order SQL injection?
Developers must ensure that all SQL processing is uniformly secure, regardless of whether the data comes directly from a user or from an internal database source.