T09 · Insecure Skill Coding Practices
- Location
scripts/screenshot.js:84- Finding
Unrestricted Browser Navigation Enables Server-Side Request Forgery
- Content
View full analysis
Vulnerability Details
File Location:
scripts/screenshot.js:84-99
Vulnerability Type: Server-Side Request Forgery and unsafe URL handling
Risk Level: HighVulnerable Code
javascript const url = args[0]; const outputPath = args[1] || './screenshot.png'; // Validate URL try { new URL(url); } catch (e) { console.error('Invalid URL:', url); process.exit(1); } takeScreenshot(url, path.resolve(outputPath)) .then(result => { console.log(JSON.stringify(result)); })The unchecked URL is subsequently passed to the browser navigation sink:
javascript await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });Technical Analysis
The validation only verifies that the input can be parsed by the JavaScript
URLconstructor. It does not enforce an allowed protocol, reject embedded credentials, restrict destination hosts, resolve and validate destination IP addresses, or validate redirect targets.Consequently, a requester can instruct Chromium to connect to resources available from the host's network context. Potential destinations include loopback services, private network addresses, link-local endpoints, and cloud instance metadata services. A public URL that redirects to a prohibited internal destination can also bypass validation because redirects are not inspected.
Because the requested resource is rendered and captured as an image, information returned by an internal service may become visible in the generated screenshot. The exact information exposed depends on services reachable from the execution environment and whether those services require authentication.
Attack Path
- An attacker asks the agent to capture a screenshot of an internal or link-local URL, such as a loopback service or cloud metadata endpoint.
- The URL passes validation because it is syntactically valid.
page.goto()causes Chromium to issue the r ...[truncated 977 chars]
- Remediation
View remediation
Remediation Suggestions
- Allow only explicitly supported protocols, preferably
https:and, if required,http:. - Reject URLs containing embedded usernames or passwords.
- Resolve the hostname before navigation and reject every address in loopback, private, link-local, multicast, reserved, and cloud metadata ranges for both IPv4 and IPv6.
- Revalidate the destination after every redirect. Do not rely solely on validating the initial URL.
- Protect against DNS rebinding by ensuring the browser's actual connection destination remains within the validated public address set.
- Prefer an explicit hostname allowlist when the operational use case permits it.
- Enforce network-level egress controls around Chromium so application-level validation is not the only security boundary.
- Block access to cloud metadata services at the firewall or container-network layer.
- Add automated tests covering loopback addresses, private IPv4 and IPv6 ranges, link-local addresses, unusual URL schemes, embedded credentials, redirects to internal addresses, and DNS rebinding scenarios.
- Allow only explicitly supported protocols, preferably