Sql Injection Blind Attack

SQL injection blind attacks exploit vulnerabilities where an attacker can inject malicious SQL code but cannot see the direct results of their queries. Unlike classic SQL injection where error messages reveal database structure, blind SQL injection relies on indirect inference through response timing, content differences, or boolean logic.

The core technique involves crafting SQL statements that return different results based on whether a condition is true or false. For example, an attacker might append OR 1=1 to a WHERE clause to force it to always return true, or OR 1=2 to force it to always return false. By observing how the application responds to these variations, attackers can gradually reconstruct database information.

Common blind SQL injection techniques include:

• Boolean-based blind injection: Crafting queries that return different HTTP responses based on a condition. For instance, username=admin' AND SUBSTRING(password,1,1)='a might return a valid user record if the first character is 'a', or an error if not.
• Time-based blind injection: Using database functions like SLEEP() or BENCHMARK() to create measurable delays. An attacker might use AND IF(SUBSTRING(password,1,1)='a', SLEEP(5), 0) to pause for 5 seconds if the condition is true.
• Out-of-band blind injection: Triggering the database to make external requests to an attacker-controlled server, often using functions like LOAD_FILE() or UTL_HTTP.REQUEST() to exfiltrate data character by character.

The attack typically proceeds through enumeration: first determining the database type and version, then extracting table names, column names, and finally the actual data. Each character of sensitive information might require multiple requests, making blind SQL injection slower than error-based variants but still highly effective against vulnerable APIs.

APIs present unique attack surfaces for blind SQL injection. While traditional web applications might expose SQL errors through HTML responses, APIs typically return structured JSON or XML data without detailed error messages, making blind techniques more relevant.

API endpoints vulnerable to blind SQL injection often include:

• Search endpoints: /api/products?search=book' OR 1=1-- might return all products instead of filtered results, revealing that the search parameter is directly concatenated into SQL queries.
• Detail endpoints: /api/users/123 OR 1=1 might bypass authorization checks if the ID parameter isn't properly sanitized.
• Filter parameters: REST APIs with query parameters like ?status=active' AND SLEEP(5)-- can be exploited if these values are incorporated into SQL without parameterization.

Consider this vulnerable API implementation: