T09 · Insecure Skill Coding Practices
- Location
feishu_drive_client.py:399- Finding
Destructive file and folder operations do not enforce user confirmation
- Content
View full analysis
Vulnerability Details
File Location:
feishu_drive_client.py:399-428
Vulnerability Type: Missing safeguard for destructive operations
Risk Level: MediumVulnerable Code
python def delete_folder(self, folder_token: str) -> Dict: url = f"{self.base_url}/files/{folder_token}" headers = self._get_headers() response = requests.delete(f"{url}?type=folder", headers=headers) return response.json() def delete_file(self, file_token: str) -> Dict: url = f"{self.base_url}/files/{file_token}" headers = self._get_headers() response = requests.delete(f"{url}?type=file", headers=headers) return response.json()Technical Analysis
The public deletion methods immediately send authenticated HTTP
DELETErequests after receiving a file or folder token. They do not accept a confirmation parameter, verify prior user approval, display the target metadata, or provide another programmatic safeguard against accidental invocation.This conflicts with the documentation, which states that deletion must be confirmed and advertises deletion as requiring forced confirmation. The confirmation mechanism exists only in example wrapper functions in
README.mdandSKILL.md; callers can bypass those examples and invokedelete_file()ordelete_folder()directly.Because the methods use the client's tenant access token, the deletion request executes with all relevant Drive privileges granted to the configured Feishu application.
Attack Path
- The Skill is initialized with valid Feishu application credentials and write privileges.
- An agent, integration, or untrusted input supplies or selects a valid file or folder token.
- The caller invokes
delete_file(token)ordelete_folder(token)directly. - The method obtains an authenticated bearer token without checking for explicit user approval.
- An HTTP
DELETErequest is sent to the Feishu Drive API. - The s ...[truncated 490 chars]
- Remediation
View remediation
Remediation Suggestions
- Add an explicit confirmation requirement to each destructive public method, such as
confirmed: bool = False. - Refuse to issue the request unless confirmation is explicitly true.
- Retrieve and present the target's name, type, and token before requesting confirmation.
- Keep low-level unguarded deletion helpers private and prevent agents from invoking them directly.
- Consider requiring a short-lived confirmation token bound to the exact target rather than a reusable Boolean.
- Record deletion attempts and outcomes without logging bearer tokens or application secrets.
- Update the documentation so its claims precisely match the implemented safeguards.
Example hardening:
python def delete_file(self, file_token: str, confirmed: bool = False) -> Dict: if not confirmed: raise PermissionError( "Explicit confirmation is required before deleting a file" ) url = f"{self.base_url}/files/{file_token}" headers = self._get_headers() response = requests.delete(f"{url}?type=file", headers=headers) return response.json()- Add an explicit confirmation requirement to each destructive public method, such as