T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/fetch.py:66
- Finding
- Unrestricted URL Navigation Enables Server-Side Request Forgery## Vulnerability Details **File Location**: `scripts/fetch.py`, lines 66–79 **Vulnerability Type**: Server-Side Request Forgery through unrestricted browser navigation **Risk Level**: High ### Vulnerable Code ```python # 访问页面 page.goto(url, wait_until="networkidle") # 等待动态内容加载 page.wait_for_timeout(wait_time * 1000) # 提取页面信息 result = { "url": url, "title": page.title(), "content": page.content(), "text": page.inner_text("body"), "status": "success" } ``` The URL originates from an unrestricted positional command-line argument: ```python parser.add_argument("url", help="URL to fetch") ``` ### Technical Analysis The skill passes a user-controlled URL directly to Playwright's `page.goto()` without validating the URL scheme, hostname, resolved IP address, port, or redirect destinations. Consequently, Chromium sends requests from the machine on which the skill executes rather than from the user's external network position. An attacker able to control the argument can target loopback addresses, link-local addresses, private network ranges, internal DNS names, or cloud instance metadata services. The browser then extracts the response title, complete HTML, and body text. These values are serialized to standard output or a caller-selected output file, creating a direct channel for disclosing reachable content. Validation must account for DNS resolution and every redirect. Checking only the original URL string would remain vulnerable to redirects, alternate numeric IP representations, IPv6 addresses, or DNS rebinding. ### Attack Path 1. An attacker supplies a URL that identifies a service reachable from the execution environment, such as a loopback administration interface, an RFC 1918 host, or a link-local metadata endpoint. 2. The command-line parser accepts the URL without restrictions. 3. `page.goto()` causes the headless browser to request the selected destination using the host's network access. 4. If the destination redirects, the ...[truncated 1056 chars]
- Remediation
- ## Remediation Suggestions 1. Restrict accepted schemes to `https` and, only where operationally necessary, `http`. Reject URL credentials, ambiguous hostnames, and all other schemes. 2. Resolve the destination hostname before navigation and reject every address in loopback, private, link-local, multicast, unspecified, documentation, and reserved ranges for both IPv4 and IPv6. 3. Explicitly deny cloud metadata destinations, including link-local metadata addresses and provider-specific metadata hostnames. 4. Intercept Playwright requests and validate each destination before allowing it. This must cover main-frame navigation, redirects, subresources, pop-ups, frames, and script-initiated requests. 5. Re-resolve and revalidate hosts at request time to reduce DNS-rebinding exposure. Ensure the browser connects to the validated address. 6. Prefer a strict allowlist of approved domains when the expected use case permits it. 7. Apply outbound firewall or proxy controls so the browser process cannot reach loopback, internal networks, management interfaces, or metadata services even if application-level validation is bypassed. 8. Add tests for IPv4 and IPv6 loopback addresses, private ranges, link-local addresses, encoded or alternative IP representations, internal DNS names, redirects to blocked destinations, and DNS-rebinding scenarios.