T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:44
- Finding
- Unsecured Local Persistence of Sensitive Lark Report Data## Vulnerability Details **File Location**: `SKILL.md`, lines 44–50 **Vulnerability Type**: Plaintext sensitive-data persistence and unsafe temporary-file handling **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown ### Step 4: Extract Submitted Members Data - Same page may show multiple weeks — only extract rows belonging to target week - Paginate through all rows for the target week - **Append to local file after each extraction** (prevents data loss) ``` ### Technical Analysis The Skill instructs the agent to append extracted weekly-report data to a local file after every extraction. Such data may contain confidential business reports, employee identities, and submission information. The instruction does not define: - An approved private storage directory - Owner-only file permissions - Encryption at rest - A randomized and collision-resistant filename - A retention period - Cleanup on success or failure - Restrictions against writing into shared or source-controlled directories Consequently, sensitive records may remain on disk beyond the task's lifetime. An unspecified local path could also expose the data through backups, source-control operations, shared workspaces, permissive filesystem settings, or access by other local processes and users. The Skill's authenticated access to Lark and its Lark-only network operations are consistent with its declared collection, document-creation, and notification functionality. No non-Lark exfiltration endpoint was identified. The confirmed weakness is the insufficiently controlled local persistence step. ### Attack Path 1. A user asks the Skill to collect reports for a team and target week. 2. The agent accesses Lark through the user's authenticated browser session. 3. The agent extracts report contents and employee submission data. 4. Following the Skill's mandatory instruction, it appends each extraction to an unspecified local file. 5. The file remains after the report summary is generated bec ...[truncated 834 chars]
- Remediation
- ## Remediation Suggestions 1. Process report data in memory and avoid writing it to disk unless persistence is strictly necessary. 2. If temporary persistence is required, use an explicitly approved private temporary directory outside shared workspaces and repositories. 3. Create files atomically with owner-only permissions, such as mode `0600`, and use randomized, non-predictable filenames. 4. Store only the minimum fields needed to produce the requested summary. 5. Encrypt temporary data at rest when the execution environment cannot guarantee exclusive access. 6. Delete temporary files immediately after document creation, including cleanup in error, cancellation, and timeout paths. 7. Define and enforce a short retention limit for recoverable intermediate data. 8. Prevent temporary artifacts from entering source control, logs, telemetry, or backups. 9. Obtain explicit user approval before retaining report data beyond the active execution. 10. Restrict collection to the user-requested templates and weeks, and restrict document sharing and notification recipients to those explicitly authorized.