Find the interpreters in your own architecture
Task
Run the four-question pass over an application you can read, locating the injection class from the design rather than from a scanner.
Steps
- Write
lab/input-paths.csvwith headerentry_point,untrusted,interpreter,separation,blast_radius. - Enumerate every entry point where untrusted input enters, INCLUDING data read back from your own store that was originally user-supplied.
- For each, name the interpreter it reaches -- database engine, shell, template engine, parser, deserialiser, browser -- or
none. - For each that reaches one, record what separates instruction from data:
parameterised,argument_array,contextual_encoding,schema, orvalidation_only. Avalidation_onlyrow is an outstanding question, not a fix. - Record the blast radius: the identity the interpreter runs as and what it can reach. Then narrow ONE over-broad identity for real.
Verify
awk -F, 'NR>1 {n++} END {print n" entry point(s)"}' lab/input-paths.csv
awk -F, 'NR>1 && $2=="yes" {n++} END {print n+0" untrusted"}' lab/input-paths.csv
awk -F, 'NR>1 && $4=="validation_only" {n++} END {print n+0" mitigated but not fixed"}' lab/input-paths.csv
awk -F, 'NR>1 {print $3}' lab/input-paths.csv | sort -u | wc -l
Five or more entry points, at least two distinct interpreters, and the validation-only count stated. If no entry point reads data back from your own store, you have missed the path that produces stored cross-site scripting -- output treated as trusted because it came from the database.
This is an independent study companion for CompTIA SecurityX CAS-005 and is not produced by or endorsed by CompTIA.