Command Injection
Some web features are thin wrappers around a command-line tool: ping a host, convert an image, zip some files. If the application builds that command by gluing in user input, the boundary between "data the tool works on" and "instructions the shell runs" can break down. This exercise explains the pattern at a conceptual level and focuses on how to recognise it and shut it down — the same data-versus-code idea you met in SQL injection, in a new place.
Log in or create a free account to submit keys and track your progress.
What you will learn
- Explain how an application can end up treating user input as shell instructions
- Understand why the shell is the risky middleman
- Recognise the pattern in a running app and in source code
- Explain the fix: avoid the shell, pass arguments as a list, validate with an allowlist
Before you start
These exercises cover what this one builds on.
- Where Web Bugs Come From Easy
- SQL Injection Medium
In this exercise
- A feature that calls a shell
- Where the boundary breaks
- Why it is so serious
- Recognising it
- The fix: don't involve the shell
🔒
This is a Pro exercise
Pro unlocks every exercise, the written solutions, the video walkthroughs and badge certificates. Free exercises stay free.
See Pro plans Create a free account5 sections · 2 keys · 50 points