exploiting-sql-injection

Fires SQL injection payloads against authorized staging targets to confirm exploitability of static scan findings.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/bs-koo/gx-security --skill exploiting-sql-injection-bs-koo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: exploiting-sql-injection
Source: https://github.com/bs-koo/gx-security/tree/main/skills/exploiting-sql-injection
Command: npx skills add https://github.com/bs-koo/gx-security --skill exploiting-sql-injection-bs-koo

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires requests, sqlmap, and includes scripts (resource) and references (resource) components.

What problem does it solve? Static scanners flag SQL injection candidates but cannot prove they are actually exploitable, leaving teams unsure which findings are real. This Skill dynamically confirms exploitability by firing real SQLi payloads at running local or staging targets, producing evidence-backed verdicts. ## Core Features & Use Cases - Multi-technique confirmation: Sequentially attempts Error-based, Boolean-based Blind (noise-floor calibrated), and Time-based Blind detection, with automatic sqlmap integration when installed and a manual PoC fallback when it is not. - Fail-closed safety gate: Every launch passes through scope_guard, which blocks production-like hosts (www.*, prod, public IPs) at the code level and only permits localhost, loopback, or explicitly allowlisted staging targets. - Evidence-based reporting: Generates a four-element report (vulnerable point, root cause, exploitation method, fix) with actual requests, responses, and timing data attached as JSON evidence. - Use Case: After a static scan flags a MyBatis ${} binding in BoardMapper.xml, run this Skill against the corresponding staging endpoint to confirm a Time-based Blind SQLi via pg_sleep and attach the measured delay evidence to the remediation ticket. ## Quick Start Ask the AI to verify whether the SQL injection candidate found by the static scan is actually exploitable against http://localhost:8080/board?id=1 using the id parameter.

Frequently Asked Questions about exploiting-sql-injection

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I confirm a SQL injection vulnerability is exploitable?▼

Run the attack_sqli.py script against a local or staging URL with the target parameter specified. It tries sqlmap first if installed, then falls back to manual Error-based, Boolean-based Blind, and Time-based Blind payloads, returning a JSON verdict with evidence.

What SQL injection techniques does this tool test?▼

It tests Error-based, Boolean-based Blind, and Time-based Blind injection, plus UNION-based extraction via sqlmap. Time-based payloads prioritize PostgreSQL pg_sleep, with MySQL SLEEP, MSSQL WAITFOR, and Oracle DBMS_PIPE variants included.

Can I run SQL injection tests against a production website?▼

No. The scope_guard safety gate blocks production-like hosts such as www.* and *prod* domains, public IPs, and metadata addresses at the code level. Only localhost, loopback, and explicitly allowlisted staging hosts are permitted.

Does the tool work without sqlmap installed?▼

Yes. If sqlmap is not found on the system, the script automatically falls back to its built-in manual proof-of-concept engine, which fires curated payloads and evaluates responses using error pattern matching, noise-floor-calibrated length comparison, and baseline-relative timing thresholds.

Why does Boolean-based blind detection report false positives?▼

Dynamic content like session IDs makes response lengths vary naturally. The script mitigates this by sending the true payload twice to measure a noise floor, then only confirming when the true-versus-false length difference exceeds that floor and reaches at least a 5 percent ratio.

Can it test SQL injection behind login pages or JSON APIs?▼

Yes. It supports Bearer token injection, form-based cookie login, and JSON request body injection via a dot-path parameter. Credentials can be supplied through CLI arguments, environment variables, or stdin to avoid hardcoding secrets.