T09 · Insecure Skill Coding Practices
Warning
- Location
SKILL.md:20- Finding
Unsafe Plaintext Storage and Executable Loading of API Credentials
- Content
View full analysis
" > "$HOME/.config/placed/credentials" export PLACED_API_KEY= ``` ### Technical Analysis The Skill stores the Placed API key in a plaintext file without explicitly restricting the permissions of either the directory or the file. Depending on the user's `umask`, the resulting credential file may be readable by other local users or processes. The credential file is subsequently loaded with `source`. This command interprets the entire file as shell code rather than reading the API key strictly as data. Consequently, any party capable of modifying `~/.config/placed/credentials` can insert arbitrary shell commands that will execute under the account running the Skill. The documented save procedure also places a user-provided value directly into generated shell syntax. A specially constructed key containing shell metacharacters, command substitutions, quotes, or line breaks could alter the intended command if an agent substitutes it literally. Credential access is necessary for the authenticated API request, but executable configuration loading and unrestricted plaintext storage exceed the minimum privileges and behavior required. ### Attack Path 1. The Skill creates `~/.config/placed/credentials` without explicitly setting restrictive permissions. 2. A local user, compromised process, or other principal with file access reads or modifies the credential file. 3. To steal the credential, the attacker reads the plaintext `PLACED_API_KEY` and uses it to access the Placed API as the vi ...[truncated 1244 chars]- Remediation
View remediation
"$credential_file" chmod 600 "$credential_file" ``` 4. Do not interpolate a user-provided key into generated shell source. Accept it through a protected input mechanism, assign it to a quoted variable, and write it using `printf '%s\n'`. 5. Prefer an operating-system credential manager or secret store instead of a plaintext file where available. 6. Avoid displaying the key in logs, command output, prompts, or error messages. 7. Validate the credential file before use: require a regular file owned by the current user, reject symbolic links, and reject files with group or world permissions. 8. Document credential revocation and rotation procedures in case an existing plaintext key has been exposed. ]]>