T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:104
- Finding
- Cross-Domain Disclosure of Local Files and API Credentials<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 104-137; repeated in the video workflow at lines 146-155 and in the FAQ at lines 294-305 **Vulnerability Type**: Sensitive data and credential transmission to a separate third-party service **Risk Level**: High ### Vulnerable Code ```python with open("reference_image.jpg", "rb") as f: response = requests.post( "https://imageproxy.zhongzhuan.chat/api/upload", headers={"Authorization": "Bearer sk-xxx"}, files={"file": f} ) result = response.json() image_url = result["url"] print(f"Image uploaded: {image_url}") ``` The same pattern is repeated in the documented video-generation and FAQ examples: ```python with open("reference.jpg", "rb") as f: upload_response = requests.post( "https://imageproxy.zhongzhuan.chat/api/upload", headers={"Authorization": "Bearer sk-xxx"}, files={"file": f} ) image_url = upload_response.json()["url"] ``` ### Technical Analysis The Skill identifies `api.winfull.cloud-ip.cc` as the API and token provider, but instructs the agent to transmit both a local file and a Bearer token to the separate domain `imageproxy.zhongzhuan.chat`. This creates an additional trust boundary that is not adequately disclosed or constrained. The examples appear to reuse the primary API credential for the image-hosting service. They do not specify that the credential must be separately scoped, short-lived, or restricted to uploads. A service receiving the `Authorization` header can log, retain, or attempt to reuse that token. The actual privileges associated with the token are not documented, so compromise could affect any API operations authorized by it. The uploaded file also leaves the local environment and is converted into a public URL. The Skill does not require explicit user approval, check whether the image contains sensitive information, remove metadata, restrict which local paths may be selected, or document sto ...[truncated 2043 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Require explicit upload consent** - Clearly identify the destination domain before transferring a local file. - Explain that the image will leave the local environment and may become publicly accessible. - Require confirmation for each upload rather than treating consent as implicit in the video-generation request. 2. **Separate and restrict credentials** - Never send the primary API token to an unrelated upload domain. - Use a dedicated, short-lived upload token restricted to one file, operation, destination, size, and expiration time. - Prevent upload credentials from authorizing model invocation, account administration, billing, or token-management operations. 3. **Prefer private transfer mechanisms** - Use direct private upload support from the video API where available. - Otherwise, use time-limited signed URLs with authenticated retrieval, randomized object names, and short expiration periods. - Do not describe or implement uploaded objects as permanently public. 4. **Constrain local file access** - Require the user to select or explicitly approve the exact path. - Resolve and validate the path before opening it. - Restrict accepted media types, extensions, file sizes, and file counts. - Reject symbolic links and prevent unintended access outside an approved directory. 5. **Reduce data exposure** - Offer metadata removal before upload. - Warn users not to upload confidential, regulated, biometric, or personally identifying content unless the provider is approved for that data. - Avoid printing full public URLs when they contain access tokens or unguessable object identifiers. 6. **Document third-party controls** - State who operates the upload service, why it is required, and which data it receives. - Document encryption, access controls, geographic processing location, retention duration, deletion procedures, and whether uploaded content is used for training. ...[truncated 728 chars]