T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:349
- Finding
- Troubleshooting Guidance May Expose Reusable Authentication Credentials<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 65–72, 136–146, and 349–352 **Vulnerability Type**: Sensitive credential disclosure through diagnostic collection **Risk Level**: Medium ### Vulnerable Snippets ```markdown Successful response (simplified): ```json { "login_token": "sess-...", "expires_at": "2025-01-01T00:00:00Z", "consumer": { ``` ```markdown Sample response (**save the `api_key` securely; only returned once!**): ```json { "id": "key-uuid", "api_key": "sk-consumer-...", "prefix": "sk-cons", ``` ```markdown 3. When troubleshooting: - Request the **full API HTTP response** (status + JSON). - Use `error.code` and context to select remediation steps. ``` ### Technical Analysis The skill instructs agents to request a full HTTP response during troubleshooting. Other sections establish that API responses can contain sensitive bearer credentials, including: - A wallet-authentication `login_token` - A newly generated consumer `api_key` - Account and wallet identifiers - Potentially sensitive diagnostic or authorization metadata The guidance does not require users to redact secrets before sharing the response. Because bearer tokens and API keys authorize requests based on possession, exposing them in a conversation, transcript, telemetry system, or support log can permit replay by anyone who obtains the value. The API-key creation response is especially sensitive because the skill states that the plaintext key is returned only once. Requesting the complete response can therefore defeat the intended one-time disclosure control. ### Attack Path 1. A user encounters an authentication, API-key creation, balance, or inference error. 2. Following the skill, the agent requests the full HTTP status and JSON response. 3. The user pastes an unsanitized response containing a `login_token`, consumer API key, or other sensitive value. 4. The credential becomes stored in conversation history, logs, monitoring data, or ...[truncated 887 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions Replace the instruction to request the full response with a strict sanitization policy: ```markdown When troubleshooting, request only the HTTP status, sanitized `error.code`, and sanitized `error.message`. Never request or reproduce authorization headers, cookies, login tokens, API keys, wallet signatures, private keys, signed messages, or complete credential-creation responses. ``` Additional hardening should include: 1. Provide a mandatory redaction checklist for `login_token`, `api_key`, `Authorization`, `Cookie`, signatures, nonces, and confidential account fields. 2. Tell users to replace sensitive values with placeholders before sharing output. 3. Recommend immediate revocation or rotation whenever a token or key is accidentally disclosed. 4. Avoid echoing secrets in agent responses, command history, screenshots, or logs. 5. Request the minimum diagnostic data required: HTTP status, error code, endpoint name, request ID, and a sanitized error message. 6. Add examples of safe, redacted responses so users do not paste complete credential-bearing JSON. ]]>