高级 SQLi 与 NoSQLi 技术

You've learned about basic SQL injection (SQLi), where direct user input manipulates database queries. However, attackers use more subtle and complex methods to bypass defenses.

In this lesson, we'll explore these 'advanced' SQLi techniques, like blind and second-order injections, and then shift our focus to NoSQL injection vulnerabilities. Most importantly, we'll cover how to defend against them effectively!

Blind SQL Injection (Blind SQLi) occurs when an application is vulnerable to SQLi, but its HTTP responses do not directly show the results of the SQL query or any error messages.

Instead, an attacker must infer information by observing the application's behavior or response times. There are two main types of Blind SQLi:

• Boolean-based Blind SQLi: The attacker observes changes in page content (e.g., a specific message appears or disappears) based on true/false conditions of injected statements.
• Time-based Blind SQLi: The attacker infers data by observing delays in the server's response time, triggered by injected database functions.

Attackers can use database functions that delay execution, such as SLEEP() (MySQL) or PG_SLEEP() (PostgreSQL), to infer data. If a condition they inject is true, the delay occurs; if false, it doesn't.

For example, a *vulnerable* query might be exploited to check if the first letter of a password is 'a':

A secure approach always uses parameterized queries, treating all user input as data, not code. Try running the secure example:

The best defense against blind SQLi is the same as for regular SQLi: parameterized queries or prepared statements. These methods ensure that SQL code is strictly separated from user input.

By treating all user-provided data as literal values, it becomes impossible for an attacker to inject malicious commands, regardless of whether the output is visible or not.

• Always validate and sanitize user input rigorously.
• Use a Web Application Firewall (WAF) to filter malicious requests.
• Monitor database access patterns for anomalies or unusually long query times.

Second-Order SQL Injection occurs when malicious input is first stored in a database (or another persistent storage) and then later retrieved and used in another query without proper re-sanitization.

This type of injection is often harder to detect during initial testing because the first interaction with the input might seem harmless. The vulnerability only manifests when the stored data is used in a different context or at a later time.

Think of it like a delayed-action bomb – the fuse is lit now, but the explosion happens later!

Consider a scenario where a user registers with a username like 'admin'--. When this username is initially stored, it might be handled safely.

However, later, an admin panel fetches user details using a query constructed by concatenating the stored username:

If $username_from_db (which now contains 'admin'--) is not re-sanitized before being used in this second query, the comment (--) could truncate the query. This might allow the attacker to bypass conditions or reveal sensitive data, as the query effectively becomes SELECT email FROM users WHERE username = 'admin'.

NoSQL databases, such as MongoDB, Cassandra, and Redis, do not use the traditional SQL query language. However, they are still vulnerable to injection attacks if user input is not handled correctly.

Attackers manipulate the data structures (e.g., JSON, BSON, XML) used in NoSQL queries to:

• Bypass authentication and gain unauthorized access.
• Access or modify unauthorized data.
• Perform denial-of-service attacks by crafting complex queries.

The specific techniques depend heavily on the NoSQL database type and its unique query language or API.

A common NoSQL injection technique in MongoDB involves manipulating query operators. MongoDB queries often use JSON-like objects with special operators (e.g., $eq for equals, $gt for greater than, $ne for not equal).

If a backend constructs a MongoDB query directly from user input without validation, an attacker could inject these operators. For example, injecting {"password": {"$ne": null}} into a password field could bypass authentication by matching any non-null password, rather than a specific one.

This allows them to find records that match conditions other than exact equality.

Consider a login function that takes a username and password. If the password is used directly in a MongoDB query without sanitation, an attacker can bypass it.

Here's a *simulated* secure Python example, showing how proper handling prevents injection, even if an attacker tries to pass a crafted string like '{" $ne": None}'.

The primary defense against NoSQL injection is rigorous input validation and sanitization. Since NoSQL databases have diverse query languages, the specific defenses can vary, but core principles remain:

• Whitelisting: Only allow known safe characters, patterns, or specific data types. Reject anything that doesn't fit.
• Strong Typing: Ensure that expected numbers are numbers, strings are strings, and boolean values are booleans.
• Driver APIs: Always use the NoSQL database driver's built-in APIs for query construction. These APIs are designed to prevent injection by treating user input as data, not code.
• Avoid Concatenation: Never concatenate user input directly into query strings or JSON structures without proper escaping or parameterization.
• Least Privilege: Database users should only have the minimum necessary permissions.

We've explored advanced SQL and NoSQL injection techniques that go beyond simple direct manipulation:

• Blind SQLi (both time-based and boolean-based) infers data without direct database output.
• Second-Order SQLi involves storing malicious input which is executed in a later, separate query.
• NoSQL Injection targets NoSQL query structures (e.g., MongoDB operators) to manipulate database operations.

The best defenses remain robust input validation, parameterized queries for SQL, and using safe driver APIs for NoSQL. Always assume all input is hostile and validate everything!