T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:135
- Finding
- Plaintext Storage of Sensitive Contact and Delivery Data<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 135-147 **Vulnerability Type**: Plaintext storage of sensitive personal data **Risk Level**: Medium ### Vulnerable Code ```markdown ## Local contacts database (opt-in) If the user agrees to saving contacts, maintain `~/indexcards/birthdays.json` as a local cache. ```json {"contacts": [{"name": "Kiall Wheatley", "birthday": "02-19", "relationship": "friend", "address": {"address1": "123 Main St", "city": "Springfield", "state": "IL", "zip": "62704", "country": "US"}, "phone": "+15551234567", "notes": "Loves hiking. Prefers watercolor.", "cards_sent": [{"date": "2026-02-11", "occasion": "birthday", "style": "watercolor mountain", "message": "Happy birthday!", "order_id": "e5f67c35"}]}]} ``` Rules: MM-DD birthday format (no year). Don't duplicate — match on name. Update with every new piece of info. Append to `cards_sent` after every order. Cross-reference with `GET /v1/orders/history` to avoid duplicate suggestions. ``` ### Technical Analysis The Skill instructs the agent to persist sensitive personal information in a predictable plaintext JSON file at `~/indexcards/birthdays.json`. The stored fields may include names, birthdays, relationships, full postal addresses, telephone numbers, personal notes, card messages, and order history. User consent controls whether the file is created, but it does not mitigate the security risks arising after creation. The instructions do not require owner-only file permissions, encryption at rest, secure atomic writes, ownership checks, integrity validation, data minimization, or a retention period. Consequently, the effective protection of the file depends on the runtime's default umask, home-directory permissions, backup configuration, and access available to other local processes. Because the same file is later used to prefill delivery information, unauthorized modification presents an integrity risk in addition to confidentiality exposure. ...[truncated 1796 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Store contact records in an operating-system-provided encrypted credential or application-data facility rather than a plaintext JSON file. 2. If file-based storage is unavoidable: - Create the parent directory with mode `0700`. - Create the data file with mode `0600`. - Set permissions explicitly instead of relying on the process umask. - Reject symbolic links and verify the file owner, type, and permissions before every read or write. - Use atomic writes through a securely created temporary file in the same protected directory. 3. Encrypt sensitive fields at rest using a key held by the operating-system keychain or secret store. Do not store the encryption key beside the data. 4. Minimize retained data. Store only fields the user separately authorizes and avoid retaining card messages, personal notes, telephone numbers, or full addresses when they are no longer required. 5. Provide explicit commands to inspect, update, export, and permanently delete stored records. 6. Define a retention period and automatically remove stale delivery information unless the user renews consent. 7. Treat cached addresses as untrusted input. Display the complete address clearly and require explicit confirmation immediately before every irreversible order. 8. Record or verify a trusted contact identifier rather than matching records only by name, which can collide or be manipulated. ]]>
