T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:87
- Finding
- Sensitive Wallet Results Can Be Redirected to Arbitrary Destinations<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:21, 87-111` **Vulnerability Type**: Unrestricted transmission of wallet signatures and transaction results **Risk Level**: High ### Vulnerable Code Snippet ```markdown - `redirect_url` (optional): where to redirect after success/failure with the result. ``` ```markdown ### Option B: redirect_url (automatic return) If you include `redirect_url`, the app redirects after success or failure. It appends query params (default mode): - On success: - `resultType=string` and `result=<value>` OR - `resultType=json` and `result=<JSON.stringify(value)>` - On failure: - `error=<message>` Template mode (no bridge, good for messaging apps): - If `redirect_url` contains `{{...}}`, placeholders are replaced and no query params are appended. - Placeholders: - `{{result}}`: URL-encoded result string (or URL-encoded `JSON.stringify(result)`) - `{{result_raw}}`: unencoded result string (or `JSON.stringify(result)`) - `{{resultType}}`: `string` or `json` - `{{error}}`: URL-encoded error message - `{{error_raw}}`: unencoded error message Implementation note for agents: - Consider generating a “compose draft” deep link into your chat with the user and using that as `redirect_url` so, after approval, the user lands in a pre-filled message back to you containing the result. ``` ### Technical Analysis The skill permits the caller to choose a `redirect_url` to which wallet operation results are transmitted. These results may include transaction hashes, message signatures, typed-data signatures, structured JSON responses, or error information. The documented design does not require: - An allowlist of trusted redirect origins. - HTTPS for redirect destinations. - Origin or destination validation. - Explicit disclosure of the final result recipient. - User confirmation before transmitting a signature. - Separation between ordinary transaction identifiers and authorization-bearing cryptographic signat ...[truncated 1914 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Make manual result return the default and recommended workflow, especially for signatures. 2. Restrict `redirect_url` to HTTPS destinations on an explicit allowlist of trusted origins. 3. Parse and validate redirect URLs rather than relying on string-prefix checks. 4. Reject embedded credentials, nonstandard schemes, user-information components, loopback addresses, private network addresses, and redirect chains to untrusted origins. 5. Remove the `{{result_raw}}` and `{{error_raw}}` placeholders. Apply context-appropriate encoding to every substituted value. 6. Display the exact normalized redirect origin to the user before wallet approval and require separate consent to transmit the result. 7. Classify wallet results by sensitivity. Do not automatically redirect typed-data signatures, permit signatures, authentication signatures, or other authorization-bearing material. 8. Use one-time, narrowly scoped callback tokens rather than placing sensitive results directly in URLs. 9. Prevent sensitive values from entering browser history, intermediary logs, analytics systems, and HTTP referrer headers. 10. Document that signatures are security-sensitive credentials and must not be sent to destinations supplied by untrusted users. ]]>
