Detecting and Preventing Injection Attacks: A Deep Dive into SQL, NoSQL, and Scanners

Code injection represents a critical class of security vulnerability where unvalidated data is added (injected) into a vulnerable program and executed. This flaw is widespread and can occur in various environments, including SQL, NoSQL, LDAP, XPath, XML parsers, and even through SMTP headers.

---

Understanding Code Injection and its Types

The insidious nature of code injection lies in its ability to bypass an application’s intended logic. Even Cross-Site Scripting (XSS) vulnerabilities are examples of code injection. When an unsanitized HTML tag containing malicious code within its attribute is submitted to a web application’s database (perhaps via a comment thread or discussion board), that code is injected into the application. This malicious script is then executed when other users view that same content, leading to a compromise.

For the purpose of this detailed analysis, the focus is squarely on detecting and preventing code injection attacks related to databases—specifically SQL Injection (SQLi) and NoSQL Injection (NoSQLi). This article explores how to use powerful Command Line Interface (CLI) tools to test form inputs for these vulnerabilities, scan for various injection attacks, and outlines best practices for avoiding damage to your target’s database during testing.

Key Topics Covered:

• SQLi and other code injection attacks
• Testing for SQLi with sqlmap
• Trawling for bugs using Google Dorks
• Scanning for SQLi with Arachni
• NoSQL injection
• An end-to-end example of SQLi reporting

---

Technical Requirements for Vulnerability Testing

To perform effective testing for injection vulnerabilities, several tools are required. In addition to using existing Burp and Burp Proxy integration with a browser like Chrome (version 66.0.3359.139 is noted), the following tools are indispensable:

• sqlmapThis is a popular CLI tool for detecting and exploiting SQL- and NoSQL-based injections. Since it is widely used, installation is flexible. It can be installed using Homebrew (brew install sqlmap) or as a Python module installable via pip. Its popularity ensures an installation path for nearly every system.
• ArachniThis tool serves as the go-to scanner for this process. While sometimes described as “noisy” (meaning it generates a lot of traffic and logs), scanners like Arachni are indispensable for the appropriate situation and excel at flushing out otherwise hard-to-detect bugs. Arachni is an excellent choice because it is open source, multi-threaded, extensible via plugins, and features a robust CLI that allows for integration into automated workflows.Arachni is easy to install, either as a Ruby gem (gem install arachni) or by downloading the official packages directly from the installation site.

Installation Note for Arachni: It is recommended to install Arachni from the site’s Download page, for example: http://www.arachni-scanner.com/download/#Mac-OS X (Please note: Always check the official website for the current installation method).

After downloading the appropriate package, it is necessary to create a symlink (symbolic link) so that all the arachni CLI packages are available within your system’s path.

Example Symlink Command:

sudo ln -s /Path/to/arachni-1.5.1-0.5.12/bin/arachni* /usr/local/bin

If you encounter an error like:

/usr/local/bin/arachni: line 3: /usr/local/bin/readlink_f.sh: No such file or directory
/usr/local/bin/arachni: line 4: readlink_f: command not found
/usr/local/bin/arachni: line 4: ./../system/setenv: No such file or directory

Simply symlink, copy, or move the readlink_f.sh script from your Arachni installation’s bin directory to your path.

Symlinking readlink_f.sh:

sudo ln -s /Path/to/arachni-1.5.1-0.5.12/bin/readlink_f.sh /usr/local/bin/readline_f.sh

With this setup, you can invoke arachni directly without typing the full path every time.

---

SQLi and Other Code Injection Attacks – Accepting Unvalidated Data

SQL Injection (SQLi) is a rather old vulnerability, with public disclosures appearing as far back as 1998 in publications like Phrack. Despite its age, it persists, often leading to critically damaging consequences.

SQLi flaws can allow an attacker to read sensitive data, update database information, and sometimes even issue OS commands. As OWASP (Open Web Application Security Project) succinctly states, the “flaw depends on the fact that SQL makes no real distinction between the control and data planes.” This means that SQL commands can modify both the data they contain and parts of the underlying system running the software. When certain access prerequisites are met, an SQLi flaw can even be used to issue system commands, demonstrated by features like sqlmap‘s --os-shell flag.

While many tools and design patterns exist for prevention, the pressure of rapidly deploying new applications and iterating quickly on features often means that SQLi-vulnerable inputs are not properly audited, and the necessary prevention procedures are neglected.

As a vulnerability endemic (commonly found) to one of the most common languages for database development, and one that is easily detected, easily exploited, and richly rewarded by attackers, SQLi is an extremely worthy subject for study.

A Simple SQLi Example

To understand how SQLi works, consider the following database query, where the value of $id would be user-supplied input:

SELECT title, author FROM posts WHERE id=$id

One common SQLi technique involves inputting data that can change the context or logic of the SQL statement’s execution. Since the $id value is being inserted directly—with no data sanitization (removal of dangerous code) or data type transformation—the SQL statement becomes dynamic and subject to tampering.

Consider a user-supplied input that changes the execution logic:

SELECT title, author FROM posts WHERE id=10 OR 1=1

In this case, 10 OR 1=1 is the user-supplied data. By modifying the WHERE clause, the user can successfully alter the logic of the developer-supplied part of the executed example. The original developer intended to retrieve only the post with ID 10, but the injected clause OR 1=1 (which is always true) effectively makes the WHERE clause true for every row, potentially returning all posts.

While the example above is relatively innocuous (harmless) for a blog post, if the statement were querying for sensitive account information from a user table, or a part of the database associated with privileges, that vulnerability could represent a way to seriously damage the application.

---

Testing for SQLi With Sqlmap – Where to Find It and How to Verify It

sqlmap is a popular CLI tool for detecting and exploiting SQLi vulnerabilities. When testing, the primary goal is discovery, though understanding the weaponization (the attacker’s use) is helpful for brainstorming possible attack scenarios for security report submissions.

The simplest use of sqlmap involves the -u flag to target the parameters being passed in a specific URL. Using webscantest.com as an example target, you can test parameters in a form submission that is specifically vulnerable to GET requests:

sqlmap -u "http://webscantest.com/datastore/search_get_by_id.php?id=3"

As sqlmap begins probing the parameters passed in the target URL, it will prompt you with questions to refine the scope of the attack:

it looks like the back-end DBMS is 'MySQL'. Do you want to skip test payloads specific for other DBMSes? [Y/n]

If the backend database management system (DBMS) can be successfully identified through separate investigations, it’s a good idea to answer Y (Yes) here to reduce potential noise in the final report.

You will also be asked about the risk level of input values you are willing to tolerate:

for the remaining tests, do you want to include all tests for 'MySQL' extending provided level (1) and risk (1) values?

Since sqlmap is designed to both detect and exploit SQLi vulnerabilities, it must be handled with care. Unless the testing is against a sandboxed instance (an isolated testing environment) completely independent from all production systems, it is crucial to select the lower risk-level settings. Using the lowest risk level ensures that sqlmap will test the form with malicious SQL inputs designed to cause the database to sleep or enumerate hidden information—and not corrupt data or compromise authentication systems. Due to the sensitivity of the information and processes in the targeted SQL database, it is paramount to tread carefully with vulnerabilities associated with backend systems.

After sqlmap runs through its range of test inputs and you have addressed all parameters passed in the targeted URL, it will print out a report of all discovered vulnerabilities.

Successful Discovery Example: A successful scan often reveals multiple vulnerabilities related to a parameter, such as a pair of blind SQLi vulnerabilities (where the results of the injection are not directly visible in the GUI), and error- and UNION-based inputs—all confirmed by the documentation on a dedicated testing site like webscantest.com.

---

Trawling for Bugs – Using Google Dorks and Python for SQLi Discovery

While sqlmap requires a URL with testable parameters, this next technique—Google Dorks—can be used to find potentially vulnerable targets first. This method can specifically target applications and form inputs, or simply return a list of sites theoretically susceptible to SQLi vulnerabilities.

Google Dorks for SQLi

Google Dorks—sometimes referred to as Google hacking—involves employing specially-crafted search queries to compel search engines to return sites that may be susceptible to SQLi and other vulnerabilities. The name “Google dork” is derived from the idea of a hapless (unfortunate) employee misconfiguring their site and exposing sensitive corporate information online.

Here are a few examples of common Google Dorks used for discovering instances of SQLi:

• inurl:index.php?id=
• inurl:buy.php?category=
• inurl:pageid=
• inurl:page.php?file=

These queries are designed to return results where the discovered sites are at least theoretically susceptible to SQLi because of their specific URL structure (i.e., passing parameters like id, category, or file in the URL).

The basic form of a dork is search_method:domain/dork, where the search_method and dork are calibrated to look for a specific type of vulnerability, and domain is used when targeting a specific application.

Example of a different dork (not for SQLi):

intitle:”EvoCam” inurl:”webcam.html”

This dork doesn’t target a particular URL; it’s simply looking for any site where the page’s title contains EvoCam and the page’s URL contains webcam.html, potentially returning insecure CCTV feeds.

Validating a Dork

Imagine discovering a dork such as this on a security site (the company title is fictionalized):

inurl:index.jsp? intext:"some company title"

This dork focuses on a particular company via the intext search filter. The jsp in the inurl value is the file extension for JSP (JavaServer Pages), a web application framework for Java servlets. JSP is older technology (Sun Microsystems’ 1999 response to Microsoft’s Active Server Pages), but like much older tech, it is still employed in legacy industries, small businesses, and small development shops.

When this dork is used in a Google search, the first result might return a URL containing index.jsp?:

http://www.examplesite.com/index.jsp?idPagina=12

This shows the site is making a GET request, passing a parameter identifying the page visited (idPagina). This URL can then be checked for vulnerability by passing it to sqlmap:

sqlmap -u "http://www.examplesite.com/index.jsp?idPagina=12"

This is a valid sqlmap command. The tool also supports an option for Dorks, -g, making it possible to pass the dork string directly to sqlmap:

sqlmap -g 'inurl:index.jsp? intext:"some company title"'

In this instance, sqlmap will use the dork to search Google, take the results from the first page, and analyze them one-by-one, prompting the user each time to ask if they want to analyze the URL, skip it, or quit.

Targeting a single result from the dork (the one passed to sqlmap via -u) might reveal both time-based and error-based SQLi vulnerabilities.

• Time-based SQLiThis technique involves calling SLEEP() or a similar function to inject a delay into the query being processed. This delay, combined with conditionals and other logic, is then used to extract information from a database by slowly enumerating resources (checking if a condition is true or false). If the injected payload produces a delay, you can infer that your condition evaluated to true, and your assumptions about the database structure or data are correct. Performing this operation enough times can expose sensitive information to determined attackers. As an attack, time-based SQLi is very noisy; while the impact on application logs is small, repeated use will cause large CPU consumption spikes, which an attentive sysadmin or Site Reliability Engineer (SRE) can easily detect.Validation Example: If a payload like 12 RLIKE SLEEP(5) is plugged into the idPagina URL parameter and the page takes longer to load, it indicates success. The SLEEP(5) command was not sanitized and was mistakenly executed by the application’s SQL server—a bona fide bug.
• Error-based SQLiThis occurs when a SQL command can be manipulated to expose sensitive database information through error messages.Validation Example: Using a specific error-based payload as the idPagina URL parameter and entering it into the browser might result in the page returning a table ID within an error message. Exposing sensitive database information more than meets the threshold for a valid SQLi vulnerability.

---

Scanning for SQLi With Arachni

As previously mentioned, Arachni is chosen as the scanner for its advantages: open source, extensible, multi-threaded, and a CLI that integrates well with automation.

After installing Arachni and symlinking its executable, you can access the arachni CLI in your $PATH. Exploring the help message reveals numerous options, though only a truncated version can be presented here. Certain CLI options are essential for extending functionality and creating more sophisticated testing workflows.

Going Beyond Defaults

Like many scanners, Arachni can be simple to use, but no extra arguments are required to start spidering a URL from the command line. However, several critical options should be used to ensure better functionality:

• --timeout: When Arachni spins up multiple threads to bombard the target with malicious snippets and exploratory requests, a Web Application Firewall (WAF) throttling traffic can cause threads to hang indefinitely. This parameter allows you to specify how long Arachni should wait before shutting down and compiling a report based on the collected data.
• –checks: By default, Arachni applies every check in its system. However, you might want to exclude certain lower-priority warnings. For example, Arachni may warn you when a company email is exposed publicly; if the email is a corporate handle meant to be customer-facing, this data leakage is not a critical issue for most companies. You might also want to exclude noisy checks that would place too much of a load on the target server or network architecture.The checks option takes arguments for checks to include and exclude, with the splat character * operating as a stand-in for all options, and excluded checks indicated by a minus sign (-).
• --scope-include-subdomains: This switch simply instructs Arachni that when it spiders a URL, it is free to follow any links it finds to that site’s subdomains.
• --plugin 'PLUGIN:OPTION=VALUE,OPTION2=VALUE2': This option allows passing environment variables that an Arachni plugin might depend on, such as authentication tokens for SaaS variables, configuration settings, or SMTP usernames and passwords.
• --http-request-concurrency MAX_CONCURRENCY: Arachni’s ability to limit its HTTP requests is crucial for preventing the target server from being overwhelmed with traffic. Even if scans are authorized, they typically have a speed limit to prevent the equivalent of a Denial-of-Service (DoS) attack. Turning down the request concurrency can also ensure you don’t get blocked by a WAF. The default is often 20 HTTP requests per second.

Writing a Wrapper Script

Just as a convenient wrapper script was used to initialize Burp’s JAR file, a similar script can be written for Arachni to avoid typing the full path and all options for every scan. This script, named ascan.sh, incorporates the options covered:

#!/bin/sh
arachni $1 \
--checks=*,-emails* \
--scope-include-subdomains \
--timeout 1:00:00 \
--http-request-concurrency 10

Like any shell script, it can be made executable with chmod u+x ascan.sh and added to the path using a symlink: sudo ln -s /Path/to/ascan.sh /usr/local/bin/ascan.

The timeout is purposefully long (1 hour) to accommodate longer hangups that occur with a smaller request pool and the extended waiting necessary because of time-based SQLi calls.

---

NoSQL Injection – Injecting Malformed MongoDB Queries

According to OWASP, there are over 150 varieties of NoSQL database available for use in web applications. To illustrate how injection works across different toolsets, we focus on MongoDB, the most widely-used, open source, unstructured NoSQL database.

The MongoDB API typically expects BSON data (binary JSON) constructed using a secure BSON query construction tool. However, in certain cases, MongoDB can also accept unserialized JSON and JavaScript expressions—notably in the case of the $where operator.

This operator is usually used as a filter, similar to the SQL WHERE operator:

db.myCollection.find( { $where: "this.foo == this.baz" } );

The expression can become more complicated. Ultimately, if the data is not properly sanitized, the MongoDB $where clause is capable of inserting and executing entire scripts written in JavaScript. Unlike SQL, which is a declarative and somewhat limited language, MongoDB’s NoSQL support for sophisticated JavaScript conditionals exposes it to exploits leveraging the language’s full range of features.

Attack patterns for this type of vulnerability are visible. Lists enumerating different malicious MongoDB $where inputs can be found on code-sharing sites.

• Denial-of-Service (DoS) and Resource Consumption Attacks: Some inputs are designed to cause significant resource consumption:JavaScript';sleep(5000); ';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000);
• Password Discovery Attacks: Others aim for information exfiltration, such as password discovery:JavaScript' && this.password.match(/.*/)//+%00

Another vector for code injection within MongoDB is available in PHP implementations. Since $where is not only a MongoDB reserved word but also valid PHP syntax, an attacker can potentially submit code into a query by creating a $where variable.

Regardless of the specific implementation, all these attacks rely on the same core principle as general injection attacks: unsanitized data being mistaken for and executed as an application command.

As the MongoDB example demonstrates, the principle of malformed input changing the logic of a developer’s code is a pervasive problem that extends well beyond SQL or any other specific language, framework, or tool.

---

SQLi – An End-to-End Example

Returning to Arachni, a scan is initiated against a test URL, for instance: https://webscantest.com/datastore.

arachni https://webscantest.com/datastore

After the scan completes (which will take time), Arachni prints the results to the console and generates an AFR file. The AFR extension stands for Arachni Framework Report and is the format Arachni uses to store scan results. This AFR file can then be converted to formats like HTML, JSON, or XML.

A scan might immediately show a vulnerability that needs detailed exploration. This is the ideal time to use the HTML version of the report for visualization of the entire scan results.

To generate a zipped HTML file from the AFR, use the arachni_reporter executable:

arachni_reporter some_report.afr --reporter=html:outfile=my_report.html.zip

Crucially, it is important to specify the outfile as zipped HTML. If the .zip suffix is omitted, the resulting HTML file will likely show a long stream of unformatted, unintelligible special characters when opened in a browser.

Once unzipped and viewed in a browser, the report provides a clear overview of the discovered issues. Drilling down, one might find instances of SQLi, such as a timing issue. The report will scroll past explanatory text and remediation guidance to show the payload and affected URLs.

Gathering Report Information

The next step is to gather all the information needed to write a professional and actionable security report.

• Category: This is a time-based SQL injection attack.
• Timestamps: Provide an estimated or actual timestamp for the finding.
• URL: The vulnerability’s URL is provided clearly in the Arachni report:http://webscantest.com/datastore/search_by_id.php
• Payload: The SQLi payload is listed prominently under injected seed:sleep(16000/1000);
• Methodology: Only use a scanner if authorized to do so! Report this finding as coming from a specific version of the Arachni scanner (e.g., v. 1.5.1).
• Instructions to Reproduce: Rather than simply pointing to the scanner, it is essential to list the steps to manually recreate the vulnerability. In this case, it might be: navigating to the form on the affected page, entering the payload, and hitting Submit. No encoding, DOM manipulation, or other tricks are required.
• Attack Scenario: When a SQL database suffers from a time-based injection attack, that vulnerability allows an attacker to enumerate information available in the database through the tactical use of expressions and the SQLi-induced pause. An attack could be used to exfiltrate business or payment data, sensitive tokens/authentication credentials, or any number of other critical pieces of information. The ability to make a SQL thread sleep is valuable because the attacker can use the timing difference to infer data. If the delay occurs, the condition they tested was True.

Final Report Submission Format

Using the gathered information, the submission can be formatted as follows:

CATEGORY: Blind SQLi (time-based)
TIME: 2018-06-18 3:23 AM (3:23) UTC
URL: http://webscantest.com/datastore/search_by_id.php
PAYLOAD: sleep(16000/1000);
METHODOLOGY: Vulnerability detected with Arachni scanner, v. 1.5.1-0.5.12

INSTRUCTIONS TO REPRODUCE:
1. Navigate to "/search_by_id.php".
2. Enter the SQLi payload into the search form.
3. Submit the query.
4. The time-based SQLi code will cause a delay in the SQL thread execution, confirming the vulnerability.

ATTACK SCENARIO:
With a time-based SQL injection vulnerability to exploit, a malicious actor could use the time-delay combined with SQL expressions to enumerate sensitive information—authentication credentials, payment data, DB information, and more—by inferring the truth of conditions based on the resulting page load time.

---

💡 Summary and Next Steps

This article covered the fundamentals of SQL and NoSQL injection, demonstrated how to use sqlmap to test a target host URL, highlighted the value of Google Dorks for both application-targeted and general vulnerability analysis, and detailed the process of scanning with Arachni and reporting a SQLi bug properly, from detection to submission.

Review Questions

1. What are blind SQLi, error-based SQLi, and time-based SQLi?

These are all sub-categories of SQL Injection (SQLi), distinguished by how you extract data from the database.

• Error-Based SQLi:
  • What it is: This is the “classic” and often easiest type. The attacker causes the database to output an error message that contains sensitive data. This is a direct, in-band attack where the error message itself is the channel for data exfiltration.
  • How it works: The payload is crafted to force a SQL error. For example, injecting ' OR 1=1 CONVERT(int, (SELECT @@version)) -- might cause a type conversion error that displays the SQL Server version in the error message.
  • Analogy: You ask a question designed to make the librarian shout out the answer in frustration.
• Blind SQLi (Boolean-Based):
  • What it is: The application does not return SQL errors or database data directly. However, the page will behave differently (a true or false condition) depending on whether the injected SQL query returns true or false.
  • How it works: The attacker asks the database a series of true/false questions. For example: ' AND (SELECT SUBSTRING(password, 1, 1) FROM users WHERE username='admin') = 'a' --. If the page loads normally, the first character is ‘a’. If it loads differently (or returns a generic error), it is not. This process is repeated character-by-character.
  • Analogy: Playing “20 Questions” with the database. “Is the first letter of the password greater than ‘m’?”
• Time-Based SQLi:
  • What it is: A sub-category of Blind SQLi where there is no visible difference in the page response at all—not even a true/false state. The only way to infer data is by asking the database to pause for a period of time based on a condition.
  • How it works: The attacker uses database functions like SLEEP(), WAITFOR DELAY, or heavy queries. For example: ' AND IF((SELECT user) = 'root', SLEEP(5), 0) --. If the page takes 5 seconds to respond, you know the database user is ‘root’.
  • Analogy: You ask the librarian a question and tell them, “If the answer is yes, take a 5-minute nap before you come back.” You don’t see the answer, but you can infer it based on how long they take to return.

2. What are some of the dangers of trying to detect SQLi vulnerabilities using aggressive string inputs (high risk payloads)?

Using aggressive payloads (e.g., ' OR 1=1; DROP TABLE users--) is extremely risky and unprofessional because it can:

• Corrupt or Delete Data: As in the example, a payload might alter table structures, delete data, or drop entire tables, causing irreversible damage.
• Cause Service Disruption (DoS): A heavy UNION select or a complex query can consume excessive database resources, slowing down or crashing the application for all users.
• Trigger Defenses and Get You Banned: Aggressive payloads are easily detected by Web Application Firewalls (WAFs) and Intrusion Detection Systems (IDS). Your IP address will likely be blocked, hindering further testing.
• Violate Bug Bounty Scope: Most programs explicitly forbid any testing that alters data or disrupts the service. Using such payloads can get you permanently banned from the program without a reward.

Best Practice: Always start with passive detection (e.g., ' to cause a syntax error) and gradually escalate to more complex, but non-destructive, payloads (e.g., using OR 1=1 to log in, or using UNION SELECT to retrieve system information like @@version).

3. What’s a Google dork? How did the technique get its name?

• What it is: A “Google dork” is a specialized search query that uses advanced Google search operators to find specific, and often sensitive, information that is publicly available but not easily accessible through a simple search. It’s a form of “Google Hacking.”
• How it got its name: The term “dork” is slang for a socially awkward person. The name was popularized by Johnny Long, a security researcher who started the “Google Hacking Database (GHDB).” He used the term self-deprecatingly, implying that while others were out being “cool” hackers, he was just a “dork” finding amazing things with simple Google searches.

4. What command-line options are particularly useful for the arachni CLI?

While Arachni has a GUI, its CLI is powerful for automation. Key options include:

• --output-save-path=FILE.afr: Saves the scan results to an AFR file for later analysis and reporting.
• --report=FORMAT:file.html: Generates a report directly after the scan (e.g., --report=html:report.html).
• --scope-page-limit=LIMIT: Limits the number of pages Arachni will crawl, preventing infinite loops on large sites.
• --checks=CHECK1,CHECK2: Specifies which vulnerability checks to run (e.g., --checks='sql_injection,*xss'). Using --checks=list shows all available checks.
• --plugin=name:key=value: Loads and configures plugins (e.g., a proxy plugin to log all traffic).
• --http-authentication-username=user --http-authentication-password=pass: For scanning password-protected areas.

5. How does one generate a report from an Arachni Framework Report (AFR) file?

You use the arachni_reporter tool. The process is simple:

1. After a scan, you have an scan.afr file.
2. Run the command: arachni_reporter scan.afr --reporter=html:outfile=report.html
   • scan.afr is your saved scan file.
   • --reporter= specifies the format and output location.
   • You can generate multiple formats (JSON, XML, PDF, etc.) from the same AFR file.

6. What are some injection vectors in MongoDB?

MongoDB uses a JSON-like query syntax (BSON), so traditional SQLi doesn’t work. The main risk is NoSQL Injection, where attackers inject JSON objects instead of SQL strings.

• Operator Injection: Exploiting query operators like $ne (not equal), $gt (greater than), or $where.
  • Example (Login Bypass): If the application code builds a query like db.users.find({user: user, pass: pass}), an attacker could submit:
    • user[$ne]=fake&pass[$ne]=fake
    • This creates the query db.users.find({user: {$ne: "fake"}, pass: {$ne: "fake"}}), which finds the first user where the username and password are not equal to “fake”—very likely the admin user!
• JavaScript Injection (Server-Side): If a query uses the $where operator, which executes JavaScript, an attacker could potentially break out of the string context and run arbitrary code.
• Boolean Injection: Injecting JSON structures that always evaluate to true to bypass authentication, similar to ' OR 1=1-- in SQLi.

7. What’s the value of being able to make a SQL thread sleep during an attack?

The primary value is for confirming and exploiting Time-Based Blind SQL Injection, as mentioned in question #1.

Data Exfiltration: It’s the mechanism for exfiltrating data. By using conditional sleeps (e.g., IF(condition, SLEEP(5), 0)), you can ask yes/no questions of the database. A delayed response means “yes,” and a normal response means “no.” This allows you to extract data one bit or one character at a time, which can be automated with tools like SQLmap.

Confirmation: It’s the definitive way to confirm a SQLi vulnerability when there are no visible errors or boolean-based differences in the page output. If you can make the database sleep and the response is delayed, you have 100% proof of injection.

Further Reading

You can find out more about some of the topics discussed in this article at:

• Arachni GitHub Page: https://github.com/Arachni/arachni
• Exploit DB: https://www.exploit-db.com
• Google Dorking: http://www.google-dorking.com