T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:25
- Finding
- Unrestricted Retrieval of User-Supplied URLs## Vulnerability Details **File Location**: `SKILL.md`, lines 25-30; fallback behavior at lines 207-210 **Vulnerability Type**: Server-Side Request Forgery risk through unrestricted network fetching **Risk Level**: Medium **Vulnerable code snippet**: ```markdown **Input**: SaaS service URL or name **Process**: 1. Crawl service landing/feature pages with `web_fetch` 2. Extract core function list 3. Decompose each function into atomic tasks ``` The fallback behavior preserves the same unrestricted retrieval capability: ```markdown ### When web_fetch Fails - Take snapshot with browser tool and analyze - Prioritize crawling public docs (help center, pricing page) ``` ### Technical Analysis The Skill accepts a SaaS URL from the user and directs a network-capable tool to retrieve it. It does not define URL validation, permitted schemes, destination restrictions, DNS resolution checks, redirect controls, response-size limits, or a prohibition against credential-bearing URLs. Consequently, a user could provide a URL that targets: - Loopback addresses such as `127.0.0.1` or `localhost` - Private network ranges - Link-local services - Cloud instance metadata endpoints - Internal administration interfaces - URLs that redirect from a public host to a restricted address Whether exploitation succeeds depends on the network access granted to `web_fetch` or the browser tool. If either tool can reach internal destinations, the documented workflow could act as an SSRF-style network proxy. Switching to the browser after `web_fetch` fails may also bypass protections that are implemented in only one of those tools. Fetched pages are untrusted input. The Skill does not instruct the Agent to disregard commands, tool requests, or behavioral instructions embedded in retrieved pages, creating an additional indirect prompt-injection risk during analysis. ### Attack Path 1. An attacker asks the Agent to decompose a se ...[truncated 1306 chars]
- Remediation
- ## Remediation Suggestions 1. Accept SaaS product names by default and resolve them through a controlled registry or search mechanism rather than directly fetching arbitrary URLs. 2. Permit only `https` URLs unless another scheme is explicitly required. 3. Reject URLs containing embedded usernames or passwords. 4. Resolve hostnames before every request and reject loopback, private, link-local, multicast, reserved, and cloud metadata address ranges. 5. Repeat destination validation after every DNS resolution and redirect to prevent DNS rebinding and redirect-based bypasses. 6. Limit redirects, response sizes, download duration, and content types. 7. Apply identical network restrictions to `web_fetch` and browser fallback tools. 8. Use an explicit allowlist when known SaaS documentation, help-center, and pricing domains are sufficient. 9. Run retrieval through an isolated egress proxy with no access to internal networks or cloud metadata services. 10. State that retrieved content is untrusted reference data and that instructions embedded in a page must never alter Agent policy, invoke tools, request secrets, or override the user's task. 11. Avoid reproducing raw fetched content when it may contain credentials, tokens, personal data, or internal configuration.