A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
Injection flaws sit at number three on the OWASP Top 10. Not number thirty. Not some footnote in an appendix. Number three, year after year, because developers keep making the same mistake: they trust user input to behave like data when the interpreter treats it as code.
That single failure cascades into dozens of vulnerability classes. The interpreter changes, but the root cause stays identical.
| Injection Type | Where User Input Lands | Typical Impact |
|---|---|---|
| OS Command Injection | system(), exec(), child_process | Full server compromise |
| SQL Injection | Database query string | Data theft, auth bypass |
| Code Injection | eval(), Function() | Arbitrary code execution |
| XSS / HTML Injection | DOM rendering | Session hijacking, phishing |
| LDAP Injection | Directory query filter | Auth bypass, info disclosure |
SQL injection gives you the database. Command injection gives you the operating system. From there, an attacker pivots laterally, dumps credentials from memory, installs persistence, and owns the entire network segment. The blast radius is not one application. It is every host that server can reach.
I have seen a single unsanitized filename parameter in a PDF generation feature lead to a full domain compromise in under forty minutes. The developer thought they were just creating a file in /tmp. They were actually handing the attacker a shell.
Command injection is not limited to web apps. Thick clients, CLI utilities, IoT firmware, and CI/CD pipelines all pass user input to system calls. The exploitation techniques in this course apply to any context where unsanitized input reaches a command interpreter.
When a pentester sees an input field, they are not thinking about the happy path. They are thinking: where does this string end up? Does it hit a database query? A shell command? A file path? An eval statement? The answer determines the injection class and the payload syntax. Everything else is technique refinement.
Next lesson, we dissect the exact code paths that create this vulnerability in PHP and NodeJS, so you can recognize them in source code during a whitebox assessment.
Finish the lesson once you have worked through the material. This awards ★ 20 XP.