T09 · Insecure Skill Coding Practices
- Location
SKILL.md:32- Finding
Unrestricted Retrieval of Client-Controlled Profile URI Enables SSRF
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 32 and 72
Vulnerability Type: Server-Side Request Forgery (SSRF) through an untrusted profile URI
Risk Level: MediumVulnerable code segments:
markdown - `UCP-Agent`: Platform's profile URI in RFC 8941 structured field format — `profile="https://..."`markdown 1. Parse `UCP-Agent` header and fetch platform profile for negotiationTechnical Analysis
The Skill directs a merchant server to extract a profile URI from the client-supplied
UCP-Agentrequest header and fetch that URI during capability negotiation. It does not require validation of the destination beyond illustrating an HTTPS URI.An implementation following these instructions may allow an unauthenticated remote client to control the destination of a server-side network request. The guidance omits essential SSRF protections, including:
- An allowlist of trusted profile origins
- Validation and normalization of the URI scheme, hostname, port, and user-information fields
- Rejection of loopback, private, link-local, multicast, reserved, and cloud-metadata addresses
- DNS-rebinding protection and validation of every resolved address
- Redirect restrictions and revalidation of redirect destinations
- Connection and response timeouts
- Response-size and content-type limits
- Safe parsing and isolation of retrieved profile data
Merely requiring HTTPS is insufficient because internal services may support HTTPS, attacker-controlled DNS can resolve to restricted addresses, and redirects can move an initially acceptable request to an internal destination.
Attack Path
- An attacker sends a checkout request to the merchant endpoint.
- The request contains a crafted
UCP-Agentheader whoseprofilevalue refers to an attacker-selected URL. - The merchant parses the header as instructed.
- During capability negotiation, the merchant server fetches the s ...[truncated 1270 chars]
- Remediation
View remediation
Remediation Suggestions
Replace unrestricted profile retrieval with a constrained and explicitly documented mechanism:
- Prefer pre-registered platform profiles or an allowlist of trusted HTTPS origins.
- Parse the URI with a standards-compliant parser and reject non-HTTPS schemes, embedded credentials, unexpected ports, malformed hosts, and ambiguous encodings.
- Resolve the hostname before connecting and reject every address in loopback, private, link-local, multicast, reserved, and cloud-metadata ranges for both IPv4 and IPv6.
- Pin the validated address for the connection or otherwise prevent DNS rebinding.
- Disable redirects where possible. If redirects are necessary, impose a small hop limit and repeat all URI and resolved-address validation for every destination.
- Apply strict connection, read, and total timeouts; cap response size; and accept only the expected profile content type and schema.
- Use a dedicated outbound proxy or sandbox with network-level egress restrictions.
- Do not return raw fetched content or sensitive connection errors to clients, and sanitize logs.
- Cache validated profiles by trusted identity rather than repeatedly fetching arbitrary client-provided locations.
- Add tests covering loopback, RFC1918, link-local, IPv6, encoded IP addresses, DNS rebinding, alternate ports, and redirect-based bypasses.
