T09 · Insecure Skill Coding Practices
- Location
SKILL.md:25- Finding
Unrestricted Retrieval of User-Supplied URLs
- Content
View full analysis
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: MediumVulnerable 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 tasksThe 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.1orlocalhost - 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_fetchor 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 afterweb_fetchfails 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
- An attacker asks the Agent to decompose a se ...[truncated 1306 chars]
- Loopback addresses such as
- Remediation
View remediation
Remediation Suggestions
- Accept SaaS product names by default and resolve them through a controlled registry or search mechanism rather than directly fetching arbitrary URLs.
- Permit only
httpsURLs unless another scheme is explicitly required. - Reject URLs containing embedded usernames or passwords.
- Resolve hostnames before every request and reject loopback, private, link-local, multicast, reserved, and cloud metadata address ranges.
- Repeat destination validation after every DNS resolution and redirect to prevent DNS rebinding and redirect-based bypasses.
- Limit redirects, response sizes, download duration, and content types.
- Apply identical network restrictions to
web_fetchand browser fallback tools. - Use an explicit allowlist when known SaaS documentation, help-center, and pricing domains are sufficient.
- Run retrieval through an isolated egress proxy with no access to internal networks or cloud metadata services.
- 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.
- Avoid reproducing raw fetched content when it may contain credentials, tokens, personal data, or internal configuration.
