T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/screenshot.sh:5
- Finding
- Unrestricted Screenshot Target and Output Path with Chromium Sandbox Disabled<![CDATA[ ## Vulnerability Details **File Location**: `scripts/screenshot.sh:5-16` **Vulnerability Type**: Server-side request forgery-like internal resource access, arbitrary file output, and unsafe browser execution **Risk Level**: High ### Vulnerable Code ```bash URL="${1:?Usage: screenshot.sh <url> <output_path> [width] [height]}" OUTPUT="${2:?Output path required}" WIDTH="${3:-1400}" HEIGHT="${4:-900}" # Use a temp HTML that loads the target in an iframe after delay, # or use virtual-time-budget to let JS execute chromium --headless --disable-gpu --no-sandbox --disable-dev-shm-usage \ --window-size="${WIDTH},${HEIGHT}" \ --screenshot="$OUTPUT" \ --hide-scrollbars \ --virtual-time-budget=5000 \ "$URL" 2>/dev/null ``` ### Technical Analysis The script accepts an arbitrary URL and output path without validating either value. Chromium can consequently be directed to network locations beyond the intended local preview server, including loopback services, private-network applications, and potentially cloud instance metadata endpoints. The unrestricted output argument also allows the caller to select any path writable by the current operating-system user. Existing files at those paths may be replaced by screenshot data. Symbolic links and sensitive application paths are not rejected. Chromium is launched with `--no-sandbox`. This removes an important containment boundary and increases the impact of a browser vulnerability or malicious page loaded by the script. Although sandbox disabling is sometimes used in restricted containers, the script does not detect such an environment or limit this behavior to cases where it is necessary. The intended visual-review functionality only requires access to the generated application on a known loopback port and output into a controlled temporary directory. Arbitrary network access, arbitrary output paths, and disabling the browser sandbox exceed those minimum requirements. ### Attack Path 1. An attacker per ...[truncated 1457 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Restrict screenshot targets to the intended development service: - Allow only `http://localhost:3002` and explicitly approved routes by default. - Parse URLs with a robust URL parser rather than string-prefix checks. - Reject embedded credentials, redirects to unapproved hosts, non-HTTP schemes, and alternate IP representations. - Resolve hostnames and block loopback, link-local, private, multicast, and metadata ranges unless individually required and approved. 2. Constrain output files: - Create a dedicated directory with restrictive permissions using `mktemp -d`. - Generate output filenames internally instead of accepting arbitrary paths. - If caller-selected names are necessary, accept only basenames and reject traversal components and symbolic links. - Avoid overwriting existing files and verify the destination with safe, race-resistant file operations. 3. Remove `--no-sandbox`. If a documented container environment truly requires it, fail closed by default and require an explicit, informed opt-in. 4. Validate width and height as bounded positive integers to prevent malformed arguments and excessive resource consumption. 5. Do not automatically share screenshots of non-public or authenticated pages. Require confirmation describing the screenshot target and recipient before transmission. ]]>