T09 · Insecure Skill Coding Practices
- Location
- skill.md:101
- Finding
- Bearer credential disclosure through a runtime-configurable provider<![CDATA[ ## Vulnerability Details **File Location**: `skill.md:52-54, 101-103` **Vulnerability Type**: Credential exposure to an unvalidated network destination **Risk Level**: High ### Vulnerable Code ```bash export AAP_ADDRESS="ai:your-name~main#www.molten.it.com" export AAP_API_KEY="your-api-key" export AAP_PROVIDER="www.molten.it.com" ``` ```bash curl "https://${AAP_PROVIDER}/api/v1/inbox?limit=10" \ -H "Authorization: Bearer ${AAP_API_KEY}" ``` ### Technical Analysis The documented inbox command interpolates `AAP_PROVIDER` directly into the destination URL while transmitting `AAP_API_KEY` as a bearer credential. The Skill does not require validation of the provider against a trusted allowlist, verify that the credential was issued for that provider, or explicitly prohibit forwarding authorization headers across redirects. Using HTTPS protects transport confidentiality but does not establish that the selected host is trustworthy. If an attacker, untrusted configuration source, or prior process can influence `AAP_PROVIDER`, the command sends the bearer token to an attacker-controlled HTTPS endpoint. Network communication and authentication are necessary for the declared messaging functionality. However, allowing a runtime-controlled host to receive a sensitive credential without origin binding exceeds the minimum privilege necessary. ### Attack Path 1. The victim obtains or configures a valid AAP API key. 2. An attacker influences the `AAP_PROVIDER` environment variable, or the victim copies an untrusted provider value into it. 3. The victim or agent executes the documented inbox retrieval command. 4. `curl` connects to the attacker-controlled provider and includes `Authorization: Bearer ${AAP_API_KEY}`. 5. The attacker records the bearer token. 6. Where accepted by the legitimate service, the attacker uses the token to retrieve or otherwise access the victim's inbox. ### Impact Assessment Successful exploitation can disclose the AAP bearer cr ...[truncated 437 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Parse and validate the provider hostname against an explicit allowlist of trusted AAP providers. - Bind each API key to the exact origin that issued it and refuse to send it to any other origin. - Reject URLs containing unexpected schemes, ports, user information, paths, or subdomain tricks. - Require HTTPS and perform normal certificate verification. - Disable redirects for authenticated requests, or strip the authorization header and revalidate the destination before following any redirect. - Separate provider configuration from untrusted message content and external agent responses. - Display the final authenticated destination and require explicit user approval when a new provider is selected. - Store the key in a dedicated secret store where available rather than broadly exposing it through inherited process environments. ]]>
