injection-testing
Skill47 starsChanged 5 months agoMITView on GitHub
Use when dynamically testing whether untrusted input reaches an interpreter — SQL/NoSQL injection (incl. blind/time-based), OS command injection, server-side template injection (SSTI), XXE, LDAP/XPath, and CRLF/header injection. Confirms on a running app what security-code-audit finds in source.
In this repository15 other files it gives its agents.
- access-control-testingSkill
- active-pentestSkill
- api-security-testingSkill
- authentication-testingSkill
- business-logic-testingSkill
- client-side-exploitationSkill
- file-upload-and-ssrfSkill
- pentest-reportingSkill
- recon-and-osintSkill
- secrets-management-auditSkill
- security-code-auditSkill
- security-hardeningSkill
- security-testingSkill
- threat-modelingSkill
- vulnerability-chainingSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 63
Only trying SQLi — SSTI, XXE, command, NoSQL hide in templates, file parsers, search, and JSON.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Injection Testing (FIND/EXPLOIT — input reaches an interpreter)
Overview
Injection happens when input crosses into a language an interpreter executes — SQL, a shell, a
template engine, an XML/LDAP/XPath parser. This skill proves it dynamically; the code-level
patterns live in security-code-audit/references/database.md and api-backend.md.
Core principle: Find where input changes the structure of a command, not just its data. A working injection is a tiny structural payload that changes the interpreter's behavior.
Applies when / Skip when
- Applies when: untrusted input can reach an interpreter — SQL/NoSQL DB, OS shell, template engine, or XML/LDAP/XPath parser.
- Skip when: a given sink type is absent → that injection class is N/A.
- If N/A: name the absent interpreters (e.g. "no SQL → SQLi N/A") and test only the sinks that exist. Partial applicability is normal here.
⚠️ Authorization
Your own/authorized app, non-prod for stateful payloads. Never --dump real data, never
--os-shell/RCE on shared systems, never ; DROP/destructive payloads. Confirm, don't damage.
Method
- Map sinks — every input that could reach a query/command/template/parser (use the audit findings).
- Probe — send a structure-breaking character and watch for a behavior change (error, different result, timing).
- Confirm — escalate from "something changed" to a controlled, benign proof.
- Bound impact — note what an attacker could reach; do not exfiltrate real data.
Quick reference — probe → confirm
| Type | Probe | Confirm (benign) | |
| SQLi | ' " ') → error/change | boolean ' OR '1'='1 ; time ' OR SLEEP(5)-- | |
| Blind SQLi | no output? | time-based / boolean differential | |
| NoSQLi | ', {"$ne":null}, [$gt]= | auth bypass via operator injection | |
| Command | ;id ` | id``id``$(id)` | out-of-band DNS, or time ;sleep 5 |
| SSTI | ${7*7} {{7*7}} <%=7*7%> | render 49 → engine-specific escalation | |
| XXE | XML with external entity | OOB fetch / file read (benign canary) | |
| LDAP | *)(uid=* | filter alteration | |
| XPath | ' or '1'='1 | node selection change | |
| CRLF | %0d%0a in reflected header | header/response splitting |
See references/injection-recipes.md for per-type detection and safe-confirmation payloads.
Tooling
sqlmap for SQLi confirmation (scoped: --batch --level/--risk low, no --dump/--os-shell),
Burp/ZAP for fuzzing, OOB via an interaction server (Burp Collaborator/interactsh) for blind/XXE.
Drive them via active-pentest.
Output
Per finding: the sink, the structural payload, the evidence of interpretation (error/time/OOB), and the bounded impact (e.g. "DB read possible"). High–Critical.
Hand-off
Often a foothold/escalation primitive → vulnerability-chaining; fix via security-hardening
(parameterization, safe APIs, allowlists, disabling external entities, output of structure-free queries).
Common mistakes
- Only trying SQLi — SSTI, XXE, command, NoSQL hide in templates, file parsers, search, and JSON.
- Missing blind injection — no visible output ≠ not vulnerable; use time/boolean/OOB.
- Going destructive to "prove it" — a
SLEEPor49proves it;DROPis vandalism. - Forgetting second-order — stored input that injects when later used in a query.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.