Injection Test

---
name: injection-test
description: >-
  Test a web app for injection flaws — SQL/NoSQL, OS command, LDAP, template
  injection, and cross-site scripting (XSS). Use to validate OWASP A03 on an
  authorized target by probing where untrusted input reaches an interpreter or sink.
---

# Goal

Evidence on whether untrusted input can break out of data context into an
interpreter (DB, shell, template, browser DOM) — with reproducible, non-destructive
proof.

# Prerequisites

- Authorization to test. Keep payloads non-destructive (prove the flaw; don't drop
  tables or run harmful commands).

# Classes to test

1. **SQL / NoSQL injection** — error-based, boolean/time-based blind; check ORDER
   BY, auth bypass, JSON/operator injection for NoSQL.
2. **Cross-site scripting (XSS)** — reflected, stored, DOM-based; test HTML, attr,
   JS, and URL contexts; check the CSP.
3. **OS command injection** — input reaching shell calls; blind via timing/OOB.
4. **Template injection (SSTI)** — input rendered by a server-side template engine.
5. **LDAP / header / other interpreter injection** as applicable.

# Steps

1. Enumerate input → sink paths (params, headers, JSON, file names, stored fields).
2. Probe each with safe marker payloads; confirm the interpreter is reached
   (reflection, error, timing, OOB callback). Use non-destructive proofs.
3. Determine context to craft a minimal working PoC (e.g. the encoding XSS needs).
4. Record: class · location · context · PoC · evidence · impact.

# Output

A results table: class · parameter/sink · context · PoC · evidence · remediation
(parameterized queries, context-aware output encoding, allow-list validation, safe
templating/sandboxing, CSP). Confirmed issues → `security-reporting:finding`.

# Notes

Fixes are sink-specific: parameterize for SQL, encode-per-context for XSS, avoid
shell for commands, sandbox templates. Input validation alone is not a reliable
fix — pair it with safe output/interpreter handling. Keep all payloads benign.