T09 · Insecure Skill Coding Practices
Error
- Location
- references/pruna-api.md:101
- Finding
- Pruna API Key May Be Disclosed to an Untrusted Delivery URL## Vulnerability Details **File Location**: `references/pruna-api.md`, lines 101–109 **Vulnerability Type**: Credential disclosure through an unvalidated response-controlled URL **Risk Level**: High **Relevant Code**: ```bash ## Download output {#download} `-o` writes (or overwrites) a local file — confirm the path with the user ([agent-safety.md](./agent-safety.md)). ```bash curl -L -H "apikey: ${PRUNA_API_KEY}" \ "GENERATION_URL_FROM_STATUS" \ -o output.bin ``` ``` The associated authentication guidance at lines 9–12 states: ```bash Send your API key in the **`apikey`** header on every request (not `Authorization: Bearer`). ```bash -H "apikey: ${PRUNA_API_KEY}" ``` ``` ### Technical Analysis The documented download command attaches `PRUNA_API_KEY` to a `generation_url` obtained from an API response without first validating the URL's scheme, hostname, port, or redirect destination. The use of `curl -L` enables redirect following. Because `apikey` is a custom header rather than a standard authentication option with clearly defined cross-origin stripping behavior, relying on curl to protect it across redirects is unsafe. More directly, if the original `generation_url` itself points to an unexpected host, the key-bearing request is immediately sent to that host. An attacker who can compromise, spoof, or otherwise influence the status response could return an attacker-controlled delivery URL. The documented workflow would then transmit the Pruna API key to the attacker. ### Attack Path 1. The agent creates and polls a Pruna prediction. 2. An attacker compromises or influences the API response path, or supplies a crafted status response containing a malicious `generation_url`. 3. The malicious URL points directly to an attacker-controlled HTTPS server or redirects to one. 4. The agent follows the documented command and invokes `curl -L`. 5. The request carries the `apikey: ${PRUNA_API_KEY}` ...[truncated 605 chars]
- Remediation
- ## Remediation Suggestions 1. Parse the returned URL before issuing a request. 2. Require an `https` scheme and an explicit allowlisted hostname, such as `api.pruna.ai`, before attaching `PRUNA_API_KEY`. 3. Reject unexpected ports, embedded user information, IP-literal hosts, malformed URLs, and non-HTTPS schemes. 4. Do not send the Pruna API key to third-party object-storage or CDN URLs. If the API returns a signed external delivery URL, download it without the `apikey` header. 5. Avoid unrestricted redirect following on authenticated requests. Validate every redirect destination or disable redirects and process them manually. 6. Separate authenticated API downloads from unauthenticated signed-URL downloads. For example: ```bash # Only after parsing and confirming that the host is exactly api.pruna.ai: curl --proto '=https' \ -H "apikey: ${PRUNA_API_KEY}" \ "$VALIDATED_PRUNA_URL" \ -o "$CONFIRMED_OUTPUT_PATH" # For a validated provider-issued signed external URL: curl --proto '=https' \ "$VALIDATED_SIGNED_URL" \ -o "$CONFIRMED_OUTPUT_PATH" ``` 7. Document that checking whether a URL is merely relative is insufficient; absolute URLs and all redirect targets must also be validated.