[This lab](https://portswigger.net/web-security/os-command-injection/lab-simple) demonstrates a classic **OS command injection** vulnerability in a stock checker feature. The application passes user-supplied input (product and store IDs) into a shell command and returns the raw output. Since the output is reflected in the response, it’s straightforward to confirm whether the command executed successfully. This kind of vulnerability is dangerous in real-world applications because it often leads directly to **remote code execution (RCE)**. Attackers can use it to pivot into internal networks, extract credentials, or take over the host system. ##### Step-by-Step Exploitation 1. Browse to a product page and click **Check Stock** 2. Intercept the request with **Burp Suite** 3. Send it to **Repeater** for editing 4. Modify the `storeId` parameter to inject a command: ``` productId=1&storeId=1|whoami ``` ![[CleanShot 2025-05-03 at 14.20.52.png]] 5. Send the request and inspect the response You should see the result of the `whoami` command in the response body, such as: ![[CleanShot 2025-05-03 at 14.21.33.png]] ##### Payload Variants You can also try these common OS injection patterns: - `1;whoami` - `1&&whoami` (use encoding) - `1|whoami` Each relies on a different shell control operator. The `|` pipes output from the first command (likely harmless) into `whoami`. ##### Why It Works The server likely uses a system command like: `stockchecker.sh <productId> <storeId>` When `storeId` includes a shell metacharacter (`|`, `;`, etc.), the shell parses and executes it as an additional command. This is a textbook example of unsafe input concatenation.