9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF

Code injection versus SQL injection

SAL1 training content groups code injection with XSS, SQL injection, and path traversal as common web attacks. Analysts must not treat every "injection" alert as the same incident type. SQL injection smuggles database language into a query. Code injection smuggles instructions into whatever interpreter the application already runs: a template engine, an eval-style language feature, or an operating-system command channel. The impact can look similar (data theft, takeover), but the artefacts differ.

Recognition for code injection starts at process telemetry, not at a payload cookbook:

• The web worker (nginx worker, httpd, java, w3wp.exe, node) spawns /bin/sh, bash, python, perl, or powershell.exe with no change ticket.
• Application logs show a 200 or 500 on an endpoint that then correlates to a child process in System Monitor (Sysmon) or Linux Audit daemon (auditd) (those tools are taught in depth in section 9.4).
• Outbound connections appear from the application host to an unknown IP immediately after that spawn — a pivot, not a browser XSS cookie theft.

Worked, sanitized host snippet after a web alert:

2026-09-18T11:07:44Z src=203.0.113.80 GET /export format=[suspicious] status=200
2026-09-18T11:07:44Z parent=w3wp.exe child=cmd.exe pid=4488 host=WEB-02
2026-09-18T11:07:45Z child=powershell.exe parent=cmd.exe

That is code injection or command injection at the recognition level: the IIS worker should not be a parent of a command shell during an export. SQLi on the same timestamp would instead show a database audit spike without a new shell. Do not copy command lines from malware reports into a lab "to try it." Preserve the tree, isolate the pool identity, and ask development which parameter maps to an interpreter.

Path and directory traversal in logs

Path traversal (also called directory traversal) occurs when user-controlled input is used to build a file path and the application fails to constrain the result to an intended directory. Attackers historically use parent-directory segments. You need to recognize those segments in telemetry, not practice them against live systems.

Analyst-visible patterns:

• Literal ../ or ..\ in the URL path or in a file, template, download, or lang query parameter.
• Encoding variants such as %2e%2e%2f or double encoding in WAF and access logs. Encoding is a bypass attempt against naive filters; seeing it in a log is an indicator, not a how-to.
• HTTP 200 responses whose body looks like an operating-system or application configuration file (password databases, web server configs, environment files, source maps) rather than the usual JSON or HTML for that route.
• Content-length far above or below the baseline for that endpoint, or Content-Type: text/plain on a route that normally returns application/json.

Worked, sanitized pair (the important comparison for this section):

# WAF (public hostname www.example.com)
2026-09-18T13:15:02Z action=block status=403 rule=path-traversal uri=/static/%2e%2e/%2e%2e/app/.env src=192.0.2.77

# Origin (same application, hostname origin-prod.internal.example.com, no WAF in path)
2026-09-18T13:15:09Z status=200 bytes=612 uri=/static/../../app/.env src=192.0.2.77 ua=same-as-blocked-request

The WAF did its job on the public name. Seven seconds later the origin returned 200 and a 612-byte body for a traversal-shaped path. Possible explanations: the client hit a hostname or port that skips the WAF; an internal tool or mis-issued certificate pointed scanners at origin; or a second URL path was not in the WAF policy. The analyst's finding is not "WAF is useless." The finding is "WAF block does not prove origin never served the file."

Input validation, patching, and WAF — what each does and does not catch

SAL1 training content names three defensive measures: input validation, patching, and WAF. Memorize the job of each so you do not close a ticket with the wrong owner.

Input validation inspects untrusted parameters at the application boundary and allows only expected types, lengths, character classes, and canonical paths. It can stop many XSS reflections, many SQLi string concatenations, and many ../ file arguments on the fields that are actually checked. It does not catch business-logic abuse (a valid ID you are not allowed to see), it fails when a developer validates the display name but not the filename, and it fails when the app decodes input after validation (canonicalization bugs).

Patching replaces vulnerable code with a fixed version: a library CVE, a framework update, or an internal hotfix. It removes the root cause for that known flaw. It does not help the night the CVE drops and the change window is next Tuesday. It does not help a custom endpoint that was never in the vendor advisory. It does not help a forgotten replica that still runs the old build. Analysts still need inventory: which host served the 200?

WAF inspects HTTP at the edge (signatures, anomaly scores, allow-lists, virtual patching). It can buy time when a patch is not installed, and it produces high-value block logs. It does not see requests that never traverse it (direct-to-origin, other ports, non-HTTP channels). It can miss encodings, multipart tricks, and JSON fields the rule set does not inspect. It is not a substitute for fixing code. A WAF 403 is evidence of an attempt; it is not evidence that the same actor failed everywhere.

Analyst comparison: WAF block versus origin 200

Use a consistent checklist when traversal or injection signatures fire:

1. Record WAF action, rule ID, and status (403, 406, 301 to a captcha, or action=allow with a logged match).
2. Query origin access logs for the same source IP, the same path family, and a ±15 minute window — including internal hostnames and default site bindings.
3. If origin is 200 and the body is a sensitive file, treat confidentiality as impacted even if the WAF also shows blocks.
4. If origin is 404/403 and WAF is block, the attempt may have failed; still hunt for siblings (other paths, other vhosts).
5. File the code fix (validation + patch) separately from the WAF rule request. Virtual patching is a stopgap, not closure.

Trap: encoded traversal that the WAF blocks as %2e%2e%2f may still succeed if the origin normalizes a different encoding the WAF does not decode the same way. Trap: a 200 with a traversal string in the referrer only is not a successful file read. Trap: static-site 200s that return HTML error pages with a 200 status can look like success until you inspect the body.

Code injection, SQLi, XSS, and traversal all share one operational moral: the HTTP status on a single hostname is not the incident. The incident is whether untrusted input became code, a query, or a file path, and whether data or control left the intended boundary. The next two sections leave the web tier and follow initial access, persistence, and credential theft on endpoints.