T09 · Insecure Skill Coding Practices
Warning
- Location
- bitable-config.json:2
- Finding
- Hardcoded Feishu Bitable Destination Can Cause Cross-Installation Data Access## Vulnerability Details **File Location**: `bitable-config.json:2-3` **Vulnerability Type**: Hardcoded external resource identifiers and unsafe shared runtime configuration **Risk Level**: Medium ### Vulnerable Code ```json { "app_token": "Tqnfb144ia0F5wsBQfCcd0lYnzh", "table_id": "tblViMOo7sfFds2h", "app_name": "AI Model Information Database (Artificial Analysis)", "table_name": "LLM Model Overview", "folder_token": "" } ``` ### Technical Analysis The distributed runtime configuration contains populated Feishu Bitable `app_token` and `table_id` values instead of placeholders. The workflow in `SKILL.md` instructs the Agent to use existing values from this file for subsequent record listing, creation, and update operations. These identifiers are not necessarily sufficient for standalone Feishu authentication. However, they select a specific external resource and become actionable when combined with an Agent's already-authorized Feishu tools. This creates a confused-deputy condition: the installing user's Feishu authorization may be used to access or modify a table selected by the Skill package author rather than a table explicitly selected by the user. Runtime resource identifiers should not be shared across installations. The Skill already includes `bitable-config.example.json` for placeholders, making inclusion of a populated runtime configuration unnecessary for its declared functionality. ### Attack Path 1. A user installs or loads the Skill package. 2. The Agent reads the committed `bitable-config.json`. 3. Because `app_token` and `table_id` are populated, the documented update workflow treats the referenced Bitable as an existing destination. 4. The Agent invokes its authorized Feishu tools using these embedded identifiers. 5. If the Agent's Feishu identity has access to the referenced resource, it may list existing records or create and update records without first confirming that the table belongs to, or was selected by, the current us ...[truncated 1131 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the populated `bitable-config.json` from the distributed Skill package. 2. Retain only `bitable-config.example.json` with clearly invalid placeholder values. 3. Add `bitable-config.json` to version-control and package ignore rules. 4. Store runtime Bitable identifiers in user-specific configuration outside the Skill installation directory. 5. Require explicit user confirmation before using an existing `app_token` and `table_id`. 6. Verify that the selected Bitable belongs to, or is intentionally accessible by, the current user before listing or modifying records. 7. On first use, create a new Bitable under the current user's authorized Feishu context unless the user explicitly supplies an existing destination. 8. Display the destination table name and URL before the first write and require confirmation when it differs from previously approved state. 9. Consider the exposed identifiers compromised for distribution purposes and replace or revoke them where supported. 10. Enforce least-privilege Feishu permissions so the Agent can access only the tables required for the current task.