SQL Injection

Technical Description

SQL Injection (SQLi) occurs when an application incorporates untrusted data into SQL queries without proper sanitization or parameterization. The attacker supplies crafted input that alters the intended query logic, enabling unauthorized operations against the backend database.

There are several distinct classes of SQL Injection:

• Classic (In-Band) SQLi: The attacker receives query results directly in the application response. This includes UNION-based injection, where additional SELECT statements are appended to retrieve data from other tables, and error-based injection, where verbose database error messages leak schema information.
• Blind SQLi: The application does not return query results or errors. The attacker infers data through boolean conditions (true/false page differences) or time-based delays (e.g., IF(condition, SLEEP(5), 0)).
• Out-of-Band SQLi: Data is exfiltrated through a separate channel, such as DNS lookups or HTTP requests initiated by the database server itself (e.g., UTL_HTTP.REQUEST in Oracle or xp_dirtree in MSSQL).
• Second-Order SQLi: Malicious input is stored in the database and later incorporated into a query in a different context, making it particularly difficult to trace.

A vulnerable query might look like:

query = f"SELECT * FROM users WHERE username = '{user_input}' AND password = '{pass_input}'"
cursor.execute(query)

An attacker supplying admin' OR '1'='1' -- as the username bypasses authentication entirely. More destructive payloads can extract entire databases, modify records, or execute operating system commands through database features like xp_cmdshell (MSSQL) or LOAD_FILE() / INTO OUTFILE (MySQL).

Real-World Impact

SQL Injection remains one of the most devastating vulnerability classes in practice:

• Heartland Payment Systems (2008): SQLi was the initial vector for a breach that exposed 134 million credit card numbers, resulting in over $140 million in damages.
• Sony Pictures (2011): LulzSec exploited a trivial SQL injection flaw to dump usernames, passwords, and personal data of over one million users.
• MOVEit Transfer (2023): A SQL injection vulnerability (CVE-2023-34362) in the MOVEit file transfer application was mass-exploited by the Cl0p ransomware group, compromising hundreds of organizations and millions of records.

Beyond data theft, SQLi enables attackers to escalate to full operating system access when database servers run with elevated privileges, pivot to internal networks, and establish persistent backdoors.

Detection Methodology

Security teams detect SQL Injection through multiple complementary approaches:

1. Static Analysis (SAST): Scan source code for string concatenation in SQL queries, missing parameterized query usage, and unsanitized user input flowing into database calls.
2. Dynamic Analysis (DAST): Submit SQLi payloads to all input vectors (parameters, headers, cookies, JSON fields) and observe application behavior for error messages, timing anomalies, or data leakage.
3. Manual Testing: Inject single quotes, comment sequences (--, #, /**/), boolean conditions (AND 1=1 vs AND 1=2), and time delays to identify injection points.
4. WAF Log Analysis: Monitor web application firewall logs for blocked SQL keywords and patterns that may indicate probing activity.
5. Database Activity Monitoring: Detect anomalous query patterns, unusual data access volumes, or queries originating from application accounts that deviate from normal behavior.

How Revaizor Discovers This

Revaizor’s AI agents approach SQL Injection testing with the contextual intelligence of a senior penetration tester rather than a simple pattern-matching scanner:

• Intelligent Input Mapping: Revaizor’s reconnaissance agents enumerate every input vector across the target application, including URL parameters, POST bodies, JSON/XML payloads, HTTP headers, and cookie values, building a comprehensive attack surface map.
• Context-Aware Payload Generation: Rather than blasting a static wordlist, Revaizor’s agents analyze the application’s technology stack and response patterns to craft targeted payloads. If the backend is PostgreSQL, it generates PostgreSQL-specific syntax; if error messages are suppressed, it shifts to blind and time-based techniques.
• Multi-Stage Exploitation: When an injection point is confirmed, Revaizor automatically escalates: enumerating databases, extracting schemas, and demonstrating data access to provide proof-of-exploitation that clearly communicates risk to stakeholders.
• Second-Order Detection: Revaizor tracks stored values across application workflows, testing whether data inserted in one endpoint triggers injection when processed by another, a class of SQLi that traditional scanners routinely miss.

Remediation

The primary defense against SQL Injection is parameterized queries (prepared statements), which separate SQL logic from data:

# Secure - parameterized query
cursor.execute(
    "SELECT * FROM users WHERE username = %s AND password = %s",
    (user_input, pass_input)
)

// Secure - PreparedStatement in Java
PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ? AND password = ?"
);
stmt.setString(1, userInput);
stmt.setString(2, passInput);

Additional defense layers include:

• Input Validation: Apply strict allowlists for expected input formats (e.g., integers, email patterns) before data reaches any query.
• Stored Procedures: Use stored procedures with parameterized inputs to encapsulate database logic, though note that stored procedures themselves can be vulnerable if they use dynamic SQL internally.
• Least Privilege: Database accounts used by applications should have the minimum permissions necessary. Never connect as sa, root, or dba from application code.
• WAF Rules: Deploy web application firewall rules as a defense-in-depth layer, but never as the sole protection.
• ORM Usage: Object-relational mappers generally produce parameterized queries, but audit raw query escape hatches (Model.objects.raw(), Sequelize.literal()) carefully.