T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:32
- Finding
- Authentication Secret Exposed in a State-Changing GET Request<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 32 **Vulnerability Type**: Secret exposure through URL query parameters and unsafe use of GET for a financial operation **Risk Level**: High ### Vulnerable Code Snippet ```http GET {DECKER_API_URL}/api/v1/link/slack/order-request?slack_user_id={sender_id}&symbol=BTC&side=buy&quantity=0.01&exchange_id=hyperliquid&openclaw_secret={OPENCLAW_SECRET} ``` ### Technical Analysis The documented order workflow places `OPENCLAW_SECRET` directly in the URL query string. URLs may be recorded by HTTP servers, reverse proxies, browser history, monitoring platforms, analytics systems, debugging tools, and network-security products. Consequently, personnel or systems with access to these records may gain access to the secret. The endpoint also uses the HTTP `GET` method for an operation that appears to create a financial order. GET requests are expected to be safe and idempotent, but intermediaries, link scanners, prefetch mechanisms, crawlers, or users may repeat them. If the server does not implement independent replay and confirmation protections, repeating the URL could repeat the order. ### Attack Path 1. A legitimate order request containing `openclaw_secret` is sent to the Decker API. 2. The full URL is retained in an access log, proxy log, browser record, diagnostic trace, monitoring platform, or support artifact. 3. An attacker or unauthorized operator obtains access to that record. 4. The attacker extracts `OPENCLAW_SECRET` and the complete order URL. 5. The attacker replays the request or modifies parameters such as `symbol`, `side`, `quantity`, or `exchange_id`. 6. If server-side authorization, expiration, confirmation, and replay controls are insufficient, the attacker can invoke the integration or submit unauthorized financial orders. ### Impact Assessment Successful exploitation may disclose an authentication credential and permit actions available to the affected OpenClaw-to-Decker ...[truncated 419 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace the state-changing GET endpoint with an HTTPS `POST` endpoint. 2. Place order parameters in a JSON request body rather than the URL. 3. Transmit credentials through an `Authorization` header, never through query parameters. 4. Use short-lived, narrowly scoped access tokens instead of a reusable integration secret. 5. Add a unique nonce, timestamp, expiration time, and server-enforced replay prevention. 6. Require an idempotency key so repeated requests cannot unintentionally create duplicate orders. 7. Bind authorization to the intended user, exchange, operation, and maximum permitted trade value. 8. Require explicit user confirmation for the final normalized trade parameters before submission. 9. Redact query strings, authorization headers, and credentials from application, proxy, monitoring, and support logs. 10. Rotate any secret that may already have appeared in URLs or retained logs. 11. Prevent caching and reject order creation through GET at the server level. ]]>