T09 · Insecure Skill Coding Practices
- Location
SKILL.md:184- Finding
Mailbox Authorization Code Stored in a Plaintext Configuration File Without Enforced Permissions
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:184-196andSKILL.md:245-250
Vulnerability Type: Plaintext sensitive credential storage with missing permission enforcement
Risk Level: MediumThe documented setup process instructs users to store a reusable 163.com mailbox authorization code in a plaintext JSON configuration file:
json { "email": "your_email@163.com", "password": "your_auth_code", "imap_server": "imap.163.com", "imap_port": 993, "smtp_server": "smtp.163.com", "smtp_port": 465 }The section presented as configuration-file permission protection does not set or verify restrictive permissions:
bash # Core implementation logic for this skill # Refer to the usage instructions above for configuration and invocation echo "implementation_ready"Technical Analysis
A mailbox authorization code is a reusable authentication secret that can grant IMAP and SMTP access. The primary setup workflow places this secret in
$HOME/.config/email-163-tool/config.jsonas plaintext.Although a later recommendation says that the file should use mode
600, the documented protection procedure only prints a status message. It does not create the directory securely, restrict the file permissions, validate ownership, or reject an existing group-readable or world-readable file.Consequently, the file's effective permissions depend on the user's umask, editor, file-copying method, and pre-existing directory permissions. On a multi-user system, container host, shared development environment, or compromised workstation, another local account or process may be able to read the authorization code.
The example value is a placeholder rather than a hardcoded production secret. The vulnerability arises when users follow the instructions and replace it with a real authorization code without effective permission enforcement.
Attack Path
- A user enables IMAP and SMTP access for a 163.com mailbox and obtains a client authoriza ...[truncated 1532 chars]
- Remediation
View remediation
Remediation Suggestions
- Make environment-variable storage or an operating-system credential manager the primary documented configuration method.
- If a configuration file is required, create the parent directory and file with restrictive permissions before writing credentials:
bash install -d -m 700 "$HOME/.config/email-163-tool" install -m 600 /dev/null "$HOME/.config/email-163-tool/config.json"- Replace the ineffective permission-protection example with commands that enforce and verify permissions:
bash chmod 600 "$HOME/.config/email-163-tool/config.json" test "$(stat -c '%a' "$HOME/.config/email-163-tool/config.json")" = "600"- On platforms where
stat -cis unavailable, provide an equivalent platform-specific check. - At runtime, verify that the file is owned by the current user and is not accessible by group or other users. Refuse to load credentials if validation fails.
- Avoid printing the authorization code in command output, logs, errors, or debugging traces.
- Document immediate revocation and replacement of the authorization code if the file may have been exposed.
- Add the configuration path to version-control ignore guidance and warn users not to copy it into shared directories, backups, support bundles, or container images.