T09 · Insecure Skill Coding Practices
Error
- Location
- references/advanced-features.md:89
- Finding
- Platform Secret Forwarded to Attacker-Controlled Destinations<![CDATA[ ## Vulnerability Details **File Location**: `references/advanced-features.md:89-103` **Vulnerability Type**: Outbound credential disclosure through an unrestricted proxy **Risk Level**: Critical ### Vulnerable Code ```typescript export default { async fetch(request: Request, env: Env): Promise<Response> { // Validate request from customer Worker const url = new URL(request.url); // Block certain domains const blockedDomains = ["internal.example.com"]; if (blockedDomains.some((d) => url.hostname.includes(d))) { return new Response("Forbidden", { status: 403 }); } // Add authentication request.headers.set("X-Platform-Auth", env.PLATFORM_SECRET); // Forward to destination return fetch(request); }, }; ``` ### Technical Analysis The outbound destination is derived directly from the incoming request. The Worker then adds the privileged `PLATFORM_SECRET` to that request before forwarding it with `fetch(request)`. The single-domain blocklist does not establish that the destination is trusted. Any attacker-controlled hostname not matching `internal.example.com` remains permitted and receives the secret. The substring comparison is also unsuitable for security validation because it can produce both incorrect blocks and incorrect trust assumptions. Adding a platform credential to a caller-controlled request exceeds the minimum privileges necessary for an outbound routing Worker. Credentials should only be attached after the destination has been matched against a strict allowlist. ### Attack Path 1. An attacker sends a request through the outbound Worker with an attacker-controlled URL as its destination. 2. The destination hostname does not contain `internal.example.com`, so the blocklist permits it. 3. The Worker adds `X-Platform-Auth: <PLATFORM_SECRET>` to the request. 4. The Worker forwards the modified request to the attacker-controlled server. 5. The attacker captures the platform secret and attemp ...[truncated 612 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace the blocklist with an exact allowlist of approved schemes, hostnames, and ports. 2. Never attach credentials to a request whose destination remains caller-controlled. 3. Construct a new outbound `Request` rather than modifying and forwarding the inbound request. 4. Copy only explicitly approved headers and discard caller-provided authentication, forwarding, and hop-by-hop headers. 5. Add the platform credential only after destination validation has succeeded. 6. Reject redirects or manually validate every redirect destination before following it. 7. Use separate, narrowly scoped credentials for each destination or service. 8. Rotate `PLATFORM_SECRET` if the vulnerable pattern has been deployed. 9. Add tests proving that arbitrary hosts, subdomains, alternate ports, non-HTTPS schemes, redirects, and malformed hostnames are rejected. A safer design should resemble: ```typescript const allowedDestinations = new Set([ "https://api.trusted.example:443", ]); const incomingUrl = new URL(request.url); const origin = `${incomingUrl.protocol}//${incomingUrl.host}`; if (!allowedDestinations.has(origin)) { return new Response("Forbidden", { status: 403 }); } const headers = new Headers(); headers.set("Content-Type", request.headers.get("Content-Type") || "application/octet-stream"); headers.set("X-Platform-Auth", env.PLATFORM_SECRET); const outboundRequest = new Request(incomingUrl, { method: request.method, headers, body: request.body, redirect: "manual", }); return fetch(outboundRequest); ``` ]]>