T09 · Insecure Skill Coding Practices
- Location
SKILL.md:132- Finding
Plaintext Storage of Email Authorization Credentials
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 132–145
Vulnerability Type: Plaintext sensitive credential storage
Risk Level: MediumThe Skill directs users to store their 163.com email address and reusable client authorization code in a local JSON configuration file:
markdown ## 配置说明 ### 配置文件位置 `./.config/email-163-com/config.json` ### 配置文件格式 ```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 }text The document subsequently acknowledges the plaintext storage risk at line 241: ```markdown - 配置文件明文存储授权码,需手动设置文件权限Technical Analysis
The documented configuration format places a reusable mailbox authorization code directly in a plaintext file. Restrictive permissions are only recommended later in the documentation and are not enforced as part of configuration-file creation or validated before use.
The documented path is also inconsistent: lines 132–145 identify
./.config/email-163-com/config.json, whereas line 220 identifies./.json. Because both are relative paths, their resolved locations depend on the process's current working directory. This ambiguity can cause credentials to be stored inside a source repository, shared workspace, backup scope, or directory readable by other users and processes.No executable implementation is included in the audited project, so runtime permission handling cannot be verified. The finding is therefore limited to the insecure credential-storage workflow explicitly prescribed by
SKILL.md.Attack Path
- A user follows the Skill documentation and writes a valid 163.com client authorization code into the documented JSON configuration.
- The file is created with default permissions, at the ambiguous
./.jsonlocation, or within a project directory without an applicable ignore rule.
...[truncated 1114 chars]
- Remediation
View remediation
Remediation Suggestions
- Store authorization codes in an operating-system credential store or dedicated secret manager rather than in JSON.
- If file-based storage is unavoidable, use one canonical absolute or user-home-relative path outside the project tree, such as a platform-specific private configuration directory.
- Create the credential file atomically with owner-only permissions (
0600on POSIX systems) and a private parent directory (0700). Do not rely on users to apply permissions afterward. - Validate file ownership, symbolic-link status, and permissions before reading the credential; reject files accessible by group or other users.
- Correct the conflict between
./.config/email-163-com/config.jsonand./.json, and clearly document the single supported location. - Add the configuration path and equivalent secret-file patterns to version-control ignore rules.
- Separate non-sensitive server configuration from credentials so only the authorization code requires protected storage.
- Avoid printing, logging, returning, or including the authorization code in command-line arguments, errors, telemetry, or generated reports.
- Provide credential rotation and revocation instructions for users who suspect exposure.
- Add automated tests that verify secure creation permissions, reject unsafe ownership or modes, and prevent secret files from being committed.