CWE-74: Injection (Generic)
Overview
This guidance helps you interpret and remediate findings from DAST (Dynamic Application Security Testing) tools. The scanner detected that the application accepted specially-crafted input containing interpreter metacharacters, and the response indicated successful injection into an interpreter (SQL, OS command, LDAP, XPath, NoSQL, etc.). DAST tools identify this by:
Detection Methods:
- SQL Injection: Testing with
' OR '1'='1,'; DROP TABLE--,UNION SELECT, time-based payloads ('; SLEEP(5)--) - OS Command Injection: Injecting command separators (
;,|,&&,||), command substitution (`whoami`,$(id)) - LDAP Injection: Testing with wildcards (
*), logical operators ()(uid=*))(|(uid=*) - XPath Injection: Submitting XPath operators (
' or '1'='1,'] | //user/*) - NoSQL Injection: Testing JSON/query operators (
{"$gt":""},{"$ne":null}) - Template Injection: Injecting template syntax (
{{7*7}},${7*7},<%= 7*7 %>)
HTTP Evidence:
- Direct Evidence: Unexpected data in responses (database records, command output, directory listings)
- Error-Based: Database error messages, interpreter syntax errors revealing injection point
- Blind/Timing: Response time delays indicating successful time-based injection (
SLEEP(10),; sleep 10) - Boolean-Based: Different responses for true vs. false conditions (
' AND '1'='1vs.' AND '1'='2) - Out-of-Band: DNS queries or HTTP callbacks to scanner infrastructure (Burp Collaborator, ZAP callback)
Scanner Behavior: OWASP ZAP (SQL Injection, Command Injection rules) and PortSwigger Burp Scanner test multiple injection contexts systematically. They use polyglot payloads, context-specific syntax, and timing analysis. Detection relies on response differential analysis, error message parsing, and out-of-band interaction monitoring.
Analyzing the Dynamic Scan Result
What the DAST Scanner Found
When reviewing your security scan results, you'll see:
HTTP Request Details
- URL and endpoint that triggered the finding
- HTTP method (GET, POST, etc.)
- Query parameters or form data with test payloads
- Request headers and body content
HTTP Response Evidence
- Response showing the vulnerability manifestation
- Evidence of improper handling or injection
- Runtime behavior indicators
Attack Vector
- Which parameter or input is vulnerable
- Type of exploitation possible
- Context where the vulnerability appears
Mapping DAST Findings to Source Code
Find the Vulnerable Endpoint
Use the HTTP request URL to locate the code:
# Search for injection-prone operations
grep -r "query" src/
grep -r "execute" src/
grep -r "eval" src/
grep -r "system" src/
Locate Interpreter Calls
Common patterns to search for:
- SQL: Query construction with user input
- OS Commands:
exec(),system(),popen() - LDAP: LDAP filter construction
- XPath: XPath query building
- NoSQL: MongoDB, Redis query injection
Find Input Handling
Search for dangerous operations:
# Find potential injection points
grep -r "execute.*+.*param" src/
grep -r "query.*format" src/
grep -r "eval.*input" src/
Trace to Vulnerable Operation
Look for injection vulnerabilities:
- SQL Injection: String concatenation in queries
- Command Injection: User input in system calls
- LDAP Injection: Unescaped input in filters
- XPath Injection: Dynamic XPath construction
- Template Injection: User input in templates
- Expression Language Injection: EL in JSP/JSF
Remediation
Core principle: Never allow untrusted input to be interpreted as code, commands, or query structure; use parameterized APIs/structured builders and context-specific encoding so input remains data.
Verification and Follow-Up Testing
After applying the fix:
Reproduce the Vulnerability
# Test SQL injection
curl "http://localhost/search?q=' OR '1'='1"
# Test command injection
curl "http://localhost/ping?host=; cat /etc/passwd"
# Test LDAP injection
curl "http://localhost/user?name=*)(uid=*))(|(uid=*"
Verify the Fix
- Confirm parameterization / structured builder is used (SQL/LDAP/XPath/etc.)
- Confirm no string concatenation at interpreter boundaries
- Confirm contextual encoding/escaping is used only where parameterization isn’t available
- Confirm allowlist validation for inputs that represent identifiers (e.g., sort fields, column names)
Test Edge Cases
# SQL injection payloads
' OR '1'='1
'; DROP TABLE users--
UNION SELECT password FROM users--
# Command injection
; ls -la
| cat /etc/passwd
`whoami`
$(cat /etc/passwd)
# LDAP injection
*)(uid=*
*)(|(uid=*
# XPath injection
' or '1'='1
'] | //user/*[contains(*,'admin
# Or use browser DevTools Network tab to copy as cURL
Re-run DAST Scanner
Run your dynamic scanner again on the fixed endpoint to confirm remediation.