T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:26
- Finding
- Plaintext Storage of Feishu Document Access Metadata and User Identifier<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:26-34` **Corroborating Location**: `config.json:1-6` **Vulnerability Type**: Plaintext sensitive-data storage **Risk Level**: Medium The Skill instructs the agent to persist a Feishu document token, full document URL, and Feishu user identifier in an ordinary plaintext configuration file. ### Vulnerable Code From `SKILL.md:26-34`: ```markdown ## 配置文件（自动生成） 所有配置项保存在技能目录下的`config.json`文件中，无需硬编码到其他文件： ```json { "schedule_doc_url": "飞书文档完整URL", "doc_token": "飞书文档token", "max_retention_days": 7, // 最大保留天数，默认7 "chatId": "ou_xxxxxxxxxxxxxxxx" // 飞书用户ID，从飞书对话中自动获取 } ``` ``` The corresponding plaintext schema appears in `config.json:1-6`: ```json { "schedule_doc_url": "", "doc_token": "", "max_retention_days": 7, "chat_id": "" } ``` The values included in the audited artifact are currently empty, so no active credential or user identifier was exposed by this copy of the project. ### Technical Analysis The design places potentially sensitive access metadata directly in `config.json` under the Skill directory. The documentation does not require restrictive file permissions, encryption at rest, a protected secret store, access isolation, log redaction, or exclusion from source control and backups. The `doc_token` may identify or authorize operations against a Feishu document, depending on the surrounding Feishu API and application authorization model. The full document URL may also expose a directly usable document reference. The `chat_id` or equivalent user identifier is persistent account metadata that can facilitate user targeting if exposed. Any local process, installed Skill, workspace user, backup service, or artifact collection process with read access to the Skill directory may be able to retrieve these values after initialization. Actual document access would remain subject to Feishu's authentication and document-permission enforcement; the token alone is not proven to byp ...[truncated 1584 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Store document credentials and access tokens in the platform's protected secret store rather than in the Skill directory. 2. Keep only a non-sensitive secret reference or opaque configuration key in `config.json`. 3. If local file storage is unavoidable: - Apply owner-only file permissions, such as mode `0600`. - Ensure the containing directory is accessible only to the service account. - Encrypt sensitive values at rest with keys held outside the project directory. 4. Add `config.json` or a generated secrets variant to source-control ignore rules, backup exclusions, support-bundle exclusions, and log-redaction policies. 5. Separate non-sensitive settings such as `max_retention_days` from sensitive document and account metadata. 6. Avoid storing the full document URL when a protected internal reference is sufficient. 7. Validate that a user identifier extracted from message context belongs to the expected authenticated Feishu tenant and account before replacing the configured identifier. 8. Apply least-privilege Feishu permissions so the integration can access only the intended schedule document and messaging recipient. 9. Support token rotation and securely delete superseded tokens. 10. Document the sensitivity of each field and fail safely when secure storage is unavailable. ]]>