T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:49
- Finding
- Insecure Plaintext API Credential Storage Guidance## Vulnerability Details **File Location**: `SKILL.md`, line 49 **Vulnerability Type**: Plaintext sensitive-data storage with unspecified file permissions **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown **Save your `api_key` immediately!** Store it as `AIXHS_API_KEY` environment variable or in `~/.config/aixhs/credentials.json`. ``` ### Technical Analysis The Skill instructs users to store a bearer API key in `~/.config/aixhs/credentials.json`, but it does not require restrictive directory or file permissions. Depending on the user's umask, operating system, backup configuration, and file-creation process, the resulting credential file could be readable by other local users or processes. The API key is a bearer credential: possession is sufficient to authenticate. Consequently, an attacker who reads the file does not need another password or cryptographic proof to impersonate the agent. Environment-variable storage can also expose the token to child processes, diagnostic tooling, or accidental logs, although it is generally preferable to embedding the secret in commands or source files. The credential is necessary for the Skill's authenticated functionality, and the documentation explicitly restricts its transmission to `https://xhs.whaty.org/api/v1/*`. Therefore, requesting the credential does not itself exceed the Skill's functional privileges. The issue is the absence of secure storage, permission, lifecycle, and revocation guidance. No evidence was found that the Skill actively reads unrelated credentials, transmits the API key to another domain, or performs hidden credential theft. ### Attack Path 1. A user registers an agent and receives an `api_key`. 2. Following the documented guidance, the user writes the key to `~/.config/aixhs/credentials.json`. 3. The file is created with permissive access rights because no secure creation procedure is specified. 4. Another local user, compromised process, bac ...[truncated 975 chars]
- Remediation
- ## Remediation Suggestions 1. Prefer an operating-system credential manager or secret-management service instead of a plaintext JSON file. 2. If file storage is required, document a secure creation procedure: ```bash install -d -m 700 ~/.config/aixhs umask 077 printf '%s\n' '{"api_key":"REPLACE_WITH_KEY"}' > ~/.config/aixhs/credentials.json chmod 600 ~/.config/aixhs/credentials.json ``` 3. Warn users not to commit the credential file to source control, include it in shared archives, paste it into prompts, or expose it through logs and screenshots. 4. Recommend limiting secret-bearing environment variables to trusted processes and removing them when no longer required. 5. Document a server-side token revocation and rotation procedure for suspected disclosure. 6. Where supported, use short-lived or narrowly scoped tokens so that posting, deletion, profile modification, and claim operations do not necessarily share one unrestricted credential. 7. Retain the existing restriction that the token must only be sent to `https://xhs.whaty.org/api/v1/*`, and recommend TLS certificate validation for every request.