T09 · Insecure Skill Coding Practices
Warning
- Location
- uptimecheck.py:12
- Finding
- Unrestricted URL Requests Enable Blind Server-Side Request Forgery<![CDATA[ ## Vulnerability Details **File Location**: `uptimecheck.py:12-13` and identical code in `scripts/uptimecheck.py:12-13` **Vulnerability Type**: Blind server-side request forgery (SSRF) through unrestricted outbound requests **Risk Level**: Medium ### Vulnerable Code ```python req = urllib.request.Request(url, method="HEAD", headers={"User-Agent": "uptimecheck/1.0"}) with urllib.request.urlopen(req, timeout=timeout) as resp: ``` ### Technical Analysis The application passes a user-supplied URL directly to `urllib.request.urlopen()` without validating its scheme, hostname, resolved IP address, or redirect destinations. URLs can be supplied as command-line arguments or loaded from a file. An attacker who can influence these inputs can cause the host running the Skill to send requests to destinations accessible from its network position, including: - Loopback services such as `127.0.0.1` or `::1` - Private network ranges - Link-local services and cloud metadata endpoints - Internal administrative or development services - Public endpoints that redirect to internal destinations Redirects are followed by the standard library handler, but redirected targets are not revalidated. Although the implementation uses `HEAD` and does not consume response bodies, status codes, errors, and response timing provide a blind network reconnaissance channel. Some non-compliant services may also perform state-changing behavior for `HEAD` requests. The same vulnerable implementation is duplicated in both executable Python files. ### Attack Path 1. An attacker supplies a crafted endpoint directly or places it in a URL input file. 2. The victim executes the `check` command in an environment with access to private services. 3. The Skill passes the URL directly to `urllib.request.urlopen()`. 4. The request originates from the victim's host and network trust boundary. 5. The attacker observes the reported status, error, and response time. 6. Repeated probes can reveal rea ...[truncated 874 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Parse every URL before making a request and permit only explicitly supported schemes, preferably `http` and `https`. 2. Require a valid hostname and reject embedded URL credentials. 3. Resolve the hostname and reject every resolved address belonging to loopback, private, link-local, multicast, unspecified, or reserved ranges. 4. Disable automatic redirects or implement a redirect handler that applies the same validation to every destination. 5. Protect against DNS rebinding by ensuring the validated address is the address used for the connection or by routing requests through a policy-enforcing proxy. 6. Consider an explicit hostname allowlist where monitoring targets are known in advance. 7. Require an explicit opt-in option for authorized internal-network monitoring. 8. Apply request-rate limits and bounded positive timeout values to reduce scanning and resource-exhaustion risks. 9. Add tests covering IPv4, IPv6, alternative address notation, DNS rebinding, and redirects from public hosts to private addresses. ]]>