Skip to main content

Overview

The SQLi Exploiter confirms SQL injection vulnerabilities and extracts data from databases to demonstrate impact. It provides a web interface for SQLMap, the industry-standard SQL injection exploitation tool. The SQLi Exploiter is an offensive tool: it actively exploits SQL injection vulnerabilities to extract database contents. It does not add data to your Attack Surface and does not generate findings. Results are displayed as a detailed report with extracted data and injection point details.

Supported targets

Target typeExamples
URLhttps://example.com/page.php?id=1
Provide the exact URL with parameters you want to test. The tool will attempt to identify and exploit vulnerable parameters.

Scan options

HTTP method

MethodDescription
GETTest parameters in the URL query string (default)
POSTTest parameters in POST data body
When using POST method, provide the POST data in the format param1=value1&param2=value2.

Enumeration

Select what data to extract from the database:
OptionDescription
Current userDatabase connection username
Current databaseActive database name
Server hostnameDatabase server hostname
BannerDatabase version and system information
UsersList of database users
PasswordsPassword hashes from user tables
TablesList of tables in databases
DatabasesList of all databases

Light crawling

When enabled, SQLMap crawls the website up to second-level links to discover additional injection points automatically. This is useful when:
  • You don’t know which exact URL is vulnerable
  • You want to test multiple pages from a starting URL
  • The vulnerable parameter might be on a linked page
Light Crawling increases scan time as it discovers and tests multiple pages. Disable it if you already know the exact vulnerable URL and parameter.

Advanced options

Toggle Advanced to access additional configuration:

Authentication

OptionDescription
Cookie headerHTTP cookies to include in requests (e.g., PHPSESSID=abc123; auth=xyz)
Use cookies to test authenticated pages or maintain session state during exploitation.
For detailed authentication configuration, see Authenticated scanning.

Injection targeting

OptionDescription
Test parametersComma-separated list of specific parameters to test (e.g., id,user). If empty, SQLMap auto-detects parameters.
Database typeForce testing for a specific database. If unset, SQLMap auto-detects.
Supported databases:
  • MySQL
  • Oracle
  • PostgreSQL
  • Microsoft SQL Server
  • Microsoft Access
  • IBM DB2
  • SQLite
  • Firebird
  • Sybase
  • SAP MaxDB
  • HSQLDB
  • Informix

Payload generation

OptionDescription
PrefixString to prepend to each payload
SuffixString to append to each payload
Use prefix/suffix when the injection point requires specific SQL syntax to close statements or comments.

Tamper scripts

Modify payloads to bypass WAFs or filters:
ScriptDescription
betweenReplace > with NOT BETWEEN 0 AND # and = with BETWEEN # AND #
charencodeURL-encode all characters in the payload
equaltolikeReplace = with LIKE
space2commentReplace spaces with inline SQL comments /**/
base64_encodeBase64-encode the payload

Detection settings

OptionRangeDescription
Level1-5Controls injection point diversity. Level 1 tests GET/POST parameters. Level 2 adds cookies. Level 3 adds User-Agent and Referer headers. Higher levels take longer.
Risk1-3Controls payload aggressiveness. Risk 2 adds heavy time-based tests. Risk 3 adds OR-based tests that may modify data. Higher risk may impact database availability.
HTTP Code100-599HTTP status code that indicates a successful injection (e.g., 200 for normal, 302 for redirect)
Risk level 3 includes OR-based SQL injection tests that could potentially modify or delete data. Use with caution and only on test environments.

Techniques

Select which SQL injection techniques to use:
TechniqueCodeDescription
Boolean-based blindBInfer data by observing true/false response differences
Error-basedEExtract data through database error messages
UNION queryUExtract data via UNION SELECT statements
Stacked queriesSExecute multiple statements separated by semicolons
Time-based blindTInfer data by measuring response time delays
Inline SQL injectionQInject into inline SQL queries
For faster scans, disable techniques you know won’t work. For example, if error messages are suppressed, disable Error-based (E).

Rate limiting

OptionRangeDescription
Delay between attempts0-600 secondsWait time between consecutive HTTP requests
Increase delay to avoid triggering rate limits or intrusion detection systems.

Form testing

OptionDescription
Test web formsWhen enabled, restricts testing to web forms only. When disabled (default), SQLMap injects payloads into URL parameters, POST data, and HTTP headers.

How it works

The SQLi Exploiter follows this process:
  1. Parameter discovery: Identifies injectable parameters in the URL, POST data, or forms
  2. Injection testing: Tests various SQL injection techniques against each parameter
  3. Database fingerprinting: Identifies the database type and version
  4. Data extraction: Extracts requested information using confirmed injection points
  5. Report generation: Displays extracted data, injection points, and SQLMap output
The report includes:
  • Summary: Current user, database, hostname, banner, and DBMS users
  • Databases and Tables: List of databases with table counts and names
  • Usernames and Passwords: Extracted credentials from user tables
  • Injection Points: Vulnerable parameters with technique and payload details
  • Console: Raw SQLMap output for detailed analysis

Important considerations

Only use exploitation tools against systems you have explicit written authorization to test. Data extraction may have legal implications even with permission.

Ethical guidelines

  • Get explicit written authorization before testing
  • Minimize data extraction, extract only enough to prove the vulnerability
  • Handle extracted data securely and delete after engagement
  • Report findings responsibly to asset owners
  • Document all actions for audit purposes

During testing

  • Avoid modifying or deleting data
  • Use lower risk levels on production systems
  • Monitor for unintended impact
  • Stop immediately if unexpected issues occur

Follow-up actions

After exploiting SQL injection:
  • Document findings: Include extracted data samples (sanitized) in reports
  • Assess full scope: Determine what other data is accessible
  • Test remediation: Re-test after fixes are applied
  • Check related issues: SQL injection often indicates broader input validation problems
  • Run Website Scanner: Check for other web vulnerabilities
  • Use Sniper: Test for additional exploitable vulnerabilities