T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:16
- Finding
- Undisclosed Multi-Provider Transmission of User Search Queries## Vulnerability Details **File Location**: `SKILL.md:16-20` and `SKILL.md:150-154` **Vulnerability Type**: Privacy disclosure mismatch and excessive query distribution **Risk Level**: Medium ### Vulnerable Code ```markdown 3. **Controlled Search**: Use web_fetch to execute search requests with rate limiting: - Add 1-2 second delay between requests to respect server load - Batch requests in groups of 3-4 engines with sequential execution between batches - Include standard browser headers to identify as legitimate user agent - If access is denied (403/429), fetch engine homepage to obtain fresh session cookies ``` The data-handling notice contradicts that network behavior: ```markdown ### Data Handling - **No Personal Data**: Tool does not collect or transmit user personal information - **Local Execution**: All operations run locally, no external data transmission - **Session Isolation**: Cookies are session-specific and cleared after use ``` ### Technical Analysis The Skill explicitly directs the agent to place user-provided search terms into URLs and submit them to batches of three or four external search providers. This network access is necessary for web-search functionality, but distributing every query to several providers is broader than the minimum access required to perform a search. Search queries may contain names, email addresses, internal project identifiers, confidential business information, personal concerns, credential-like strings, or other sensitive data. URL query parameters may be retained in provider logs, network telemetry, browser or tool history, and monitoring systems. The statement that all operations are local and involve “no external data transmission” is factually incompatible with the required `web_fetch` operations. Consequently, users may submit information under an incorrect privacy assumption. The static pre-scan finding at `references/international-search.md:185` is not evidence that an actual password is ...[truncated 1879 chars]
- Remediation
- ## Remediation Suggestions 1. Replace the inaccurate privacy statements with an explicit disclosure that search terms and request metadata are transmitted to selected third-party search engines. 2. Default to a single search provider and use additional providers only when the user requests aggregation or the first provider fails. 3. Obtain explicit user confirmation before transmitting a query to multiple providers, especially when sensitive information is detected. 4. Display the destination domains before network requests are made. 5. Warn users not to submit passwords, API keys, authentication tokens, private keys, personal identifiers, confidential documents, or proprietary internal data. 6. Apply URL encoding to all user-controlled query values and keep provider hostnames constrained to a fixed allowlist. 7. Minimize request metadata and avoid reusing identifying cookies where they are not required. 8. Document realistic cookie behavior and verify that cookies remain domain-scoped, in memory, and are cleared after each search session. 9. Replace remote password-generation examples with local generation using a cryptographically secure random-number generator. 10. Provide a privacy-preserving mode that uses one user-selected provider and disables cookie acquisition, retries, and multi-provider fan-out.