T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:104
- Finding
- Reusable Authentication Token Exposed in WebSocket URL## Vulnerability Details **File Location**: `SKILL.md:104-106` **Vulnerability Type**: Credential exposure through a URL query parameter **Risk Level**: Medium ### Vulnerable Code ```text wscat -c "wss://your-relay/ws?teamId=my-team&instanceId=my-instance&token=my-token" ``` ### Technical Analysis The documented WebSocket connection method places a reusable authentication token in the URL query string. Although `wss://` encrypts the request in transit, it does not prevent the complete URL from being exposed through other channels, including: - Shell command history - Local process inspection - Relay or reverse-proxy access logs - Monitoring and observability systems - Diagnostic and error logs Query strings are commonly logged by infrastructure components. Consequently, using a query parameter for a credential increases the likelihood of unintended token disclosure. The relay supports message delivery, queued-message retrieval, and agent activation through webhooks. A disclosed team token could therefore enable unauthorized relay access, subject to the relay server's authorization implementation and the scope assigned to that token. ### Attack Path 1. An operator replaces `my-token` with a real reusable relay token and runs the documented `wscat` command. 2. The complete command or WebSocket URL is retained in shell history, exposed through process inspection, or recorded by an intermediary or relay log. 3. An attacker with access to one of those data sources extracts the token. 4. The attacker uses the token to authenticate to the relay. 5. Depending on the relay's authorization controls, the attacker impersonates an instance, accesses queued team messages, or publishes unauthorized messages. 6. A malicious published message may reach a registered webhook and wake an agent, exposing the agent to attacker-controlled input. ### Impact Assessment Successful exploitation may provide unauthorized access to the authenticated relay messaging channe ...[truncated 515 chars]
- Remediation
- ## Remediation Suggestions - Do not transmit reusable credentials in URL query parameters. - Authenticate the WebSocket handshake with an `Authorization` header where client and server support permits. - Alternatively, obtain a short-lived, single-use WebSocket ticket through an authenticated HTTPS request and use that ticket for the connection. - Issue narrowly scoped, per-instance credentials rather than a shared team-wide token. - Apply short expiration periods and provide a documented token-rotation and revocation process. - Configure the relay, reverse proxies, monitoring systems, and error handlers to omit or redact query strings and authentication data. - Advise operators to rotate any token previously used in a URL and remove affected entries from shell histories and logs. - Authenticate message senders and validate authorization separately for publishing, consuming messages, listing resources, and registering webhooks. - Treat all relay-delivered message content as untrusted input and prevent it from being interpreted automatically as privileged agent instructions.