T09 · Insecure Skill Coding Practices
- Location
SKILL.md:20- Finding
Incomplete URL Validation May Permit Server-Side Request Forgery
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 20-29
Vulnerability Type: Incomplete SSRF protection
Risk Level: MediumVulnerable Code
markdown ### 1. URL validation — block before fetching Reject any URL that matches the following. Do not fetch, do not log, reply "skipped: non-public URL": - Private IP ranges: `10.*`, `172.16–31.*`, `192.168.*` - Loopback: `127.*`, `localhost`, `::1` - Cloud metadata: `169.254.169.254`, `169.254.170.2` - Non-HTTP schemes: `file://`, `ftp://`, `data:`, `javascript:` Only proceed if the URL is `http://` or `https://` pointing to a public hostname.The validated URL is subsequently fetched at
SKILL.md, lines 48-53:markdown ### 1. Validate the URL Before fetching, apply the URL validation rules above. Skip and notify if the URL fails. ### 2. Fetch the contentweb_fetch(url)
text Technical Analysis
The Skill correctly identifies fetched content as untrusted and explicitly blocks common private, loopback, and cloud metadata addresses. In particular, mentioning
169.254.169.254and169.254.170.2does not constitute metadata access; those addresses appear in a defensive denylist.However, the validation design relies on matching a limited set of textual URL patterns. It does not require the Agent or fetch implementation to:
- Resolve the hostname and validate every resulting IP address before connecting.
- Revalidate the destination after each HTTP redirect.
- Block all IPv4 and IPv6 link-local, private, loopback, multicast, unspecified, documentation, and reserved ranges.
- Reject alternative representations of IP addresses where supported by the URL parser.
- Prevent DNS rebinding or pin the validated address to the subsequent connection.
- Apply equivalent controls to URLs discovered through the search fallback.
Consequently, a URL may appear to contain a public hostname during initial validation while resolving or redirecting to an internal service. This creates ...[truncated 1828 chars]
- Remediation
View remediation
Remediation Suggestions
- Route all fetches through a dedicated SSRF-resistant HTTP client or proxy rather than relying on natural-language URL checks.
- Parse URLs with a standards-compliant parser and permit only HTTP and HTTPS.
- Reject URLs containing credentials, malformed authorities, ambiguous host syntax, or unsupported ports.
- Resolve the hostname before connecting and reject every result that is not globally routable.
- Cover both IPv4 and IPv6, including private, loopback, link-local, multicast, unspecified, carrier-grade NAT, reserved, and IPv4-mapped IPv6 addresses.
- Pin the connection to the validated address to mitigate DNS rebinding while preserving the intended TLS hostname verification.
- Disable redirects by default. If redirects are required, parse, resolve, and validate every redirect target before following it, with a strict hop limit.
- Apply the same validation to URLs obtained from search results or other fallback mechanisms.
- Enforce outbound network restrictions so the Agent cannot reach metadata endpoints or internal networks, even if application-level validation is bypassed.
- Configure cloud metadata defenses such as mandatory session-oriented metadata access where available, while blocking metadata IPs at the firewall or proxy.
- Ensure summaries never reproduce secrets, tokens, credentials, private keys, or sensitive internal response data.
- Add tests covering public hostnames resolving to private addresses, redirects to internal destinations, IPv6 link-local addresses, alternative IP forms, DNS rebinding scenarios, and both listed metadata endpoints.