SQL Injection Manual Testing: A Complete Guide to Detection

Imagine a scenario where a developer builds a sleek, modern login page for a corporate portal. To the average user, the interface is seamless. However, behind the scenes, the application takes the username provided in the text box and inserts it directly into a database query string. For a security professional or a curious tester, this is a red flag. By simply entering a single quote or a specific logic string, a tester can potentially trick the database into bypassing authentication or leaking thousands of private records. This is the essence of SQL injection (SQLi).

While automated vulnerability scanners are incredibly powerful and efficient, they often miss the nuance of complex business logic or get blocked by basic web application firewalls (WAFs). Manual testing remains the gold standard for confirming vulnerabilities, understanding the depth of the impact, and crafting precise payloads that avoid detection. Manual testing requires a deep understanding of how databases process queries and how web applications handle user input, turning the tester into a digital detective who looks for subtle clues in server responses.

The Fundamentals of SQL Injection

At its core, SQL injection occurs when an application fails to properly sanitize user-supplied data before using it in a database query. SQL (Structured Query Language) is the standard language used to communicate with relational databases like MySQL, PostgreSQL, Microsoft SQL Server, and Oracle. When input is concatenated directly into a query, the database cannot distinguish between the intended data and the commands injected by the user.

For example, a typical query to fetch user details might look like this: SELECT * FROM users WHERE id = 'USER_INPUT'. If the user provides 1, the query is safe. However, if the user provides 1' OR '1'='1, the query becomes SELECT * FROM users WHERE id = '1' OR '1'='1'. Since '1'='1' is always true, the database returns the first record in the table, often granting unauthorized access to an administrative account.

Common Entry Points for Testing

Manual testers don't just look at login forms. SQL injection can occur anywhere the application interacts with a database based on user-controllable input. Common vectors include:

• URL Parameters: Query strings like ?id=10&category=books are prime targets.
• POST Data: Form fields, search boxes, and contact forms.
• HTTP Headers: User-Agent, Referer, and X-Forwarded-For headers are often logged in databases and can be vulnerable.
• Cookies: Values stored in cookies that are used to track sessions or preferences in the backend.
• JSON/XML Payloads: Modern APIs that accept structured data often forget to sanitize the values within the JSON objects.

Phase 1: Identification and Reconnaissance

The first step in manual testing is identifying whether a parameter is even interacting with a database. This is done by injecting characters that are syntactically significant to SQL. The most common character is the single quote ('), but double quotes ("), semicolons (;), and parentheses ((, )) are also vital.

When you inject a single quote into a vulnerable parameter, one of three things usually happens. First, the page might return a database-specific error message (e.g., "You have an error in your SQL syntax"). This is the easiest scenario because it confirms the vulnerability immediately. Second, the page might return a generic "500 Internal Server Error," which suggests the application crashed due to the unexpected character. Third, the content of the page might change slightly—perhaps a product disappears from a list—indicating that the query logic was altered.

Testing for security gaps involves a methodical approach. Testers often use a variety of payloads to see how the server reacts. For instance, trying ' OR 1=1-- or ' OR 'a'='a helps determine if the application is susceptible to basic logical bypasses. If the server responds differently to 1=1 (True) and 1=2 (False), you have successfully identified a potential injection point.

Phase 2: Error-Based SQL Injection

Error-based SQLi is a highly efficient method where the tester intentionally triggers errors to extract information from the database. The goal is to force the database to reveal its version, table names, or column names within the error message displayed on the web page.

In a manual environment, this often starts with ORDER BY clauses. By injecting ' ORDER BY 1--, ' ORDER BY 2--, and so on, the tester can determine the exact number of columns being returned by the original query. If ORDER BY 5-- works but ORDER BY 6-- returns an error, the tester knows the original query selects five columns.

Once the column count is known, the UNION operator is used. The UNION SELECT statement allows a tester to append the results of their own query to the results of the original query. For example, ' UNION SELECT 1,2,database(),4,5-- might display the name of the current database directly on the screen in the position of the second or third column. This technique is incredibly fast but is often blocked by modern error-handling configurations that show generic "An error occurred" pages.

Phase 3: Boolean-Based Blind SQL Injection

Blind SQL injection occurs when the application does not return database errors or the results of the query directly in the response. Instead, the tester must observe a binary change in the page's behavior. This is a slower, more tedious process, but it is extremely effective for deep pentesting efforts.

Boolean-based testing relies on asking the database "Yes" or "No" questions. For example, a tester might use the following payloads:

• ?id=1 AND 1=1 (Expected result: The page loads normally)
• ?id=1 AND 1=2 (Expected result: The page loads without the specific content or shows a "Not Found" message)

If these two requests result in different page outputs, the tester can begin extracting data character by character. To find the name of the database, a tester might ask: ?id=1 AND (SELECT SUBSTRING(database(),1,1)) = 'a'. If the page loads normally, the first letter of the database name is 'a'. If it doesn't, the tester tries 'b', 'c', and so on. While this is time-consuming manually, it proves that the database is executing the injected logic.

Phase 4: Time-Based Blind SQL Injection

Time-based SQLi is the most discreet form of injection. It is used when the application provides the exact same response regardless of whether a query is True or False. In this case, the tester forces the database to wait for a specific amount of time before responding if a condition is met.

Different databases have different functions for this. MySQL uses SLEEP(), PostgreSQL uses pg_sleep(), and SQL Server uses WAITFOR DELAY. A typical payload would be ' AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)--. If the web page takes exactly five seconds longer to load than usual, the tester knows the injection was successful.

Like boolean-based testing, time-based attacks are used to extract data. A tester might inject: ' AND (SELECT IF(SUBSTRING(user(),1,1)='a', SLEEP(5), 0))--. If the response is delayed, the first letter of the database user is 'a'. Because this method relies on network latency, it requires careful timing and multiple requests to confirm that the delay is caused by the database and not by a slow internet connection.

Phase 5: Out-of-Band (OOB) SQL Injection

Out-of-Band SQLi is used when the tester cannot see the response in the HTTP body or detect a time delay reliably. This technique triggers the database to make an external network request (like a DNS or HTTP request) to a server controlled by the tester. This is a powerful way to identify a vulnerability in environments with heavy filtering.

For instance, in Microsoft SQL Server, a tester might use master..xp_dirtree to make the server attempt to access a file on a remote SMB share. In Oracle, UTL_HTTP.request can be used to send a GET request to an external URL. The tester monitors their own server logs; if they see a request coming from the target server's IP address, the injection is confirmed. This method is often the most reliable for extracting large amounts of data because the data can be appended to the subdomain of the DNS request (e.g., admin-password.attacker.com).

Advanced Manual Techniques and WAF Evasion

Modern applications often employ Web Application Firewalls (WAFs) that look for common SQL keywords like UNION, SELECT, and DROP. Manual testers must use evasion techniques to bypass these filters. One common method is using case variation, such as sElEcT instead of SELECT, although most modern WAFs handle this easily.

More sophisticated evasion includes:

• URL Encoding: Encoding characters like the single quote as %27 or using double URL encoding to trick the filter.
• Inline Comments: Inserting SQL comments inside keywords, such as SEL/**/ECT, which the database ignores but may confuse a WAF.
• Whitespace Manipulation: Using tabs, newlines, or characters like %0A (newline) instead of standard spaces.
• Using Logical Equivalents: Replacing OR 1=1 with OR 2>1 or OR 'a'='a' to avoid signature-based detection.

Remediation: Stopping SQL Injection

The only truly effective way to prevent SQL injection is to stop treating user input as executable code. The gold standard for this is the use of Parameterized Queries (also known as Prepared Statements). Instead of concatenating a string, the developer defines the SQL code first and then passes the user input as a parameter. The database engine treats the parameter strictly as data, not as part of the command, making injection impossible.

Beyond prepared statements, other layers of defense include:

• Input Validation: implementing a strict allow-list for expected input (e.g., ensuring an ID parameter only contains integers).
• Principle of Least Privilege: Ensuring the database user account used by the web application has the minimum permissions necessary. For example, the app should not have permission to drop tables or access the master database.
• Escaping All User Input: While less effective than parameterization, using functions like mysqli_real_escape_string() in PHP can provide a basic layer of defense.
• Using an ORM: Many Object-Relational Mapping frameworks (like Entity Framework or Hibernate) handle parameterization automatically.

Conclusion

Manual SQL injection testing is an art form that combines technical knowledge of database architecture with a creative approach to problem-solving. By moving systematically from simple identification to complex time-based or out-of-band techniques, a tester can uncover vulnerabilities that automated tools overlook. Understanding the underlying mechanics—how a single quote disrupts a query or how a boolean condition changes a page's state—is crucial for any security professional. However, the ultimate goal of this testing is not just to break things, but to provide developers with the evidence needed to implement robust, parameterized defenses that protect user data from real-world attackers.

Frequently Asked Questions

How can I tell if a website is vulnerable to SQL injection?
The most common indicator is observing how the site responds to special characters like the single quote ('). If the page returns a database error, changes its content significantly, or crashes (500 error), it may be vulnerable. You can further confirm this by using logical tests, such as comparing the response of a True condition (1=1) versus a False condition (1=2) in a URL parameter.

What is the difference between blind and error-based SQLi?
Error-based SQLi is direct; the database returns a specific error message that contains data or confirms the vulnerability. Blind SQLi occurs when the server suppresses errors. In blind SQLi, you must infer information by observing changes in the page content (Boolean-based) or by measuring the time the server takes to respond (Time-based).

Why is manual testing better than using automated scanners?
Automated scanners are fast but often miss complex vulnerabilities that require a specific sequence of steps or logical understanding. Manual testers can bypass WAFs using creative encoding, understand the business context of the data, and avoid the high rate of false positives that scanners often produce.

How do prepared statements prevent SQL injection?
Prepared statements separate the SQL query structure from the data. The query is pre-compiled by the database, and the user input is treated strictly as a literal value (a parameter). Because the structure is already fixed, any SQL commands injected into the parameter are simply treated as text and are never executed.

Which characters are most commonly used to test for SQLi?
\ The single quote (') is the primary tool for breaking string literals. Other common characters include the double quote ("), the semicolon (;) for stacking queries, the comment markers (-- or #) to neutralize the rest of the original query, and parentheses () to test for function-based injections.