T09 · Insecure Skill Coding Practices
Warning
- Location
- references/auth-setup.md:7
- Finding
- Underspecified Persistent Storage of API Credentials## Vulnerability Details **File Location**: `references/auth-setup.md`, lines 7–10 and 28–33 **Vulnerability Type**: Persistent plaintext credential exposure **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown ## Step 0 — how to store an env var on this system Figure out the correct way to persist an environment variable on this machine so it is available in every future session (a shell profile, or a config/env file managed by your agent runtime). The variable name is `STAYINGAPI_KEY`. ``` ```markdown ## Step 2 — store it ```bash export STAYINGAPI_KEY="stay_live_…" # or stay_test_… for the sandbox ``` ``` ### Technical Analysis The setup guide explicitly directs the Agent to make `STAYINGAPI_KEY` available in every future session and permits storage in a shell profile or Agent-managed environment file. It does not require an operating-system secret manager, owner-only file permissions, encryption, restricted process scope, log redaction, or user approval before persistent storage. The displayed `export` command is session-local when executed alone. The security issue arises from combining it with the preceding instruction to determine and implement a persistent storage mechanism. An Agent may consequently place a live, potentially billable API key in a plaintext shell initialization file or broadly accessible runtime configuration. This unnecessarily increases both the credential lifetime and the number of processes or future Agent sessions that may inherit or access it. The behavior is not evidence of malicious persistence because it stores a legitimate service credential rather than a backdoor; however, the security controls around that persistence are insufficiently specified. ### Attack Path 1. A user supplies a live `STAYINGAPI_KEY` while configuring the Skill. 2. The Agent follows Step 0 and writes the key into a shell profile or runtime environment file so that it survives future sessions. ...[truncated 1341 chars]
- Remediation
- ## Remediation Suggestions 1. Default to session-only credential injection rather than persistent storage. 2. Obtain explicit user consent before storing a key across sessions. 3. Prefer the documented OAuth 2.1 with PKCE MCP workflow or an operating-system/runtime secret manager. 4. If file-based storage is unavoidable: - Use a dedicated credential file rather than a shared shell profile. - Restrict ownership to the intended user. - Enforce owner-only permissions, such as mode `0600` on applicable systems. - Prevent the file from being committed to source control or included in ordinary backups and diagnostic bundles. - Avoid exposing the key to unrelated child processes. 5. Do not print, echo, or log the credential during setup or verification. 6. Document key revocation and rotation procedures. 7. Recommend sandbox keys for evaluation and live keys only when live data is necessary. 8. Add guidance to rotate the credential immediately if it is written to an insecure location or disclosed.