T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:28
- Finding
- Unrestricted User-Controlled URL Fetching Enables SSRF## Vulnerability Details **File Location**: `SKILL.md`, lines 28-29, 33, and 45-48 **Vulnerability Type**: Server-Side Request Forgery caused by insufficient URL validation **Risk Level**: High ### Vulnerable Code ```markdown 1. **Parse target** from `$ARGUMENTS`. - If URL (starts with `http`): use directly. 2. **Fetch the page** via WebFetch. 3. **Check infrastructure files:** - Fetch `{origin}/sitemap.xml` — exists? Valid XML? Page count? - Fetch `{origin}/robots.txt` — exists? Disallow rules? Sitemap reference? - Fetch `{origin}/favicon.ico` — exists? ``` ### Technical Analysis The skill accepts a user-controlled target when its value merely starts with `http` and directs the agent to fetch it using `WebFetch`. It then derives and requests three additional resources from the same origin. A prefix check does not establish that a destination is safe. The instructions do not reject: - Loopback destinations such as `127.0.0.1` or `[::1]` - Private or reserved network ranges - Link-local addresses and cloud instance metadata endpoints - URLs containing embedded credentials - Hostnames that resolve to restricted addresses - Redirects that lead to restricted destinations - Nonstandard ports exposing internal administrative services Consequently, the agent's network position can potentially be used as an SSRF proxy. Exploitability and accessible scope depend on the protections implemented by the underlying `WebFetch` tool and the runtime's egress policy. ### Attack Path 1. An attacker invokes the skill with an HTTP or HTTPS URL targeting an internal, loopback, link-local, or otherwise restricted service. 2. The skill accepts the input because it starts with `http`. 3. The agent requests the supplied URL through `WebFetch`. 4. The workflow may issue additional requests for `/sitemap.xml`, `/robots.txt`, and `/favicon.ico` on that origin. 5. If network-layer protections do not block the destination, the requests reach services accessible from th ...[truncated 884 chars]
- Remediation
- ## Remediation Suggestions 1. Parse targets with a standards-compliant URL parser instead of checking only the string prefix. 2. Permit only `https` by default and reject unsupported schemes, malformed URLs, embedded credentials, and unnecessary nonstandard ports. 3. Resolve the hostname before every request and reject loopback, private, link-local, multicast, reserved, unspecified, and other non-public IP ranges for both IPv4 and IPv6. 4. Protect against DNS rebinding by binding requests to validated resolution results or revalidating the actual connection destination. 5. Disable redirects where possible. Otherwise, parse, resolve, and validate every redirect destination before following it. 6. Apply the same validation to the initial page and all derived resources, including `sitemap.xml`, `robots.txt`, and `favicon.ico`. 7. Enforce network-level egress controls so the fetch runtime cannot access internal networks or metadata services. 8. Set strict request timeouts, response-size limits, redirect limits, and content-type restrictions. 9. Avoid including sensitive fetched content in reports; expose only the minimum metadata required for the SEO audit. 10. If legitimate private-site audits are required, provide a separate explicitly authorized mode with destination allowlisting and clear user confirmation.