T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:51
- Finding
- Automatic Plaintext Persistence of Sensitive Database Context## Vulnerability Details **File Location**: `SKILL.md`, lines 51–71 **Vulnerability Type**: Automatic storage of potentially sensitive operational information in plaintext files **Risk Level**: Medium ### Vulnerable Code Snippet The following is an English translation of the relevant source instructions: ```markdown ## Memory Mechanism **Automatic memory is enabled** - **Environment information**: Automatically save database environment details when first provided by the user - **Historical tasks**: Automatically record every completed task - **User preferences**: Remember the user's preferences ### Memory Storage Location memory/ ├── env.json # User environment information ├── history.json # Historical task records └── preferences.json # User preference settings ### Automatic Memory Rules 1. **At session start**: Read the memory directory and obtain user history 2. **When a new database is mentioned**: Automatically add it to env.json 3. **After completing a task**: Automatically record it in history.json 4. **When user preferences change**: Automatically update preferences.json ``` ### Technical Analysis The Skill instructs the agent to collect database environment information, completed-task history, and user preferences automatically and persist them in JSON files. DBA conversations commonly include sensitive operational information such as production database versions, host identifiers, topology, replication configuration, incident details, backup arrangements, and security settings. The instructions do not define: - Explicit user consent before persistence - A data-minimization or allowlist policy - Redaction of credentials, connection strings, tokens, query contents, or personal data - File permission requirements - Per-user or per-tenant storage isolation - Retention limits or expiration - Secure deletion procedures - Encryption at rest - Controls governing which later sessions may reload the information Although the files d ...[truncated 2101 chars]
- Remediation
- ## Remediation Suggestions 1. Disable automatic persistence by default and require explicit, informed user opt-in. 2. Define a strict allowlist of fields that may be retained, such as database product and major version only. 3. Explicitly prohibit storing passwords, tokens, private keys, connection strings, personal data, raw queries, query results, host addresses, and confidential incident evidence. 4. Display the exact information proposed for storage and obtain confirmation before writing it. 5. Store each user's data in an isolated location and prevent memory from being shared across users or tenants. 6. Apply restrictive filesystem permissions, such as owner-only read and write access, when creating memory files. 7. Encrypt sensitive persisted data at rest using runtime-managed keys rather than keys stored in the project. 8. Introduce configurable retention periods, automatic expiration, and a user-accessible command for reviewing and deleting retained data. 9. Sanitize stored values and treat reloaded memory as untrusted data rather than executable instructions. 10. Record only minimal structured metadata in task history instead of complete prompts, outputs, SQL statements, or operational logs. 11. Gracefully handle the currently absent `memory/` directory and ensure files are created securely without unsafe permissions or symbolic-link traversal.