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 type | Examples |
|---|
| URL | https://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
| Method | Description |
|---|
| GET | Test parameters in the URL query string (default) |
| POST | Test parameters in POST data body |
When using POST method, provide the POST data in the format param1=value1¶m2=value2.
Enumeration
Select what data to extract from the database:
| Option | Description |
|---|
| Current user | Database connection username |
| Current database | Active database name |
| Server hostname | Database server hostname |
| Banner | Database version and system information |
| Users | List of database users |
| Passwords | Password hashes from user tables |
| Tables | List of tables in databases |
| Databases | List 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
| Option | Description |
|---|
| Cookie header | HTTP cookies to include in requests (e.g., PHPSESSID=abc123; auth=xyz) |
Use cookies to test authenticated pages or maintain session state during exploitation.
Injection targeting
| Option | Description |
|---|
| Test parameters | Comma-separated list of specific parameters to test (e.g., id,user). If empty, SQLMap auto-detects parameters. |
| Database type | Force 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
| Option | Description |
|---|
| Prefix | String to prepend to each payload |
| Suffix | String 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:
| Script | Description |
|---|
| between | Replace > with NOT BETWEEN 0 AND # and = with BETWEEN # AND # |
| charencode | URL-encode all characters in the payload |
| equaltolike | Replace = with LIKE |
| space2comment | Replace spaces with inline SQL comments /**/ |
| base64_encode | Base64-encode the payload |
Detection settings
| Option | Range | Description |
|---|
| Level | 1-5 | Controls 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. |
| Risk | 1-3 | Controls 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 Code | 100-599 | HTTP 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:
| Technique | Code | Description |
|---|
| Boolean-based blind | B | Infer data by observing true/false response differences |
| Error-based | E | Extract data through database error messages |
| UNION query | U | Extract data via UNION SELECT statements |
| Stacked queries | S | Execute multiple statements separated by semicolons |
| Time-based blind | T | Infer data by measuring response time delays |
| Inline SQL injection | Q | Inject 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
| Option | Range | Description |
|---|
| Delay between attempts | 0-600 seconds | Wait time between consecutive HTTP requests |
Increase delay to avoid triggering rate limits or intrusion detection systems.
| Option | Description |
|---|
| Test web forms | When 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:
- Parameter discovery: Identifies injectable parameters in the URL, POST data, or forms
- Injection testing: Tests various SQL injection techniques against each parameter
- Database fingerprinting: Identifies the database type and version
- Data extraction: Extracts requested information using confirmed injection points
- 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