T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:56
- Finding
- Registration Bearer Credential Exposed in a URL Query Parameter## Vulnerability Details **File Location**: `SKILL.md`, lines 14–17 and 56–61 **Vulnerability Type**: Bearer credential exposure through a URL query parameter **Risk Level**: Medium ### Vulnerable Code ```markdown ## Authentication All requests (except `/register-agent`) use Bearer token: ```http Authorization: Bearer <registration_token> ``` ``` ```markdown { "agent_id": "agt_abc123", "wallet_id": "wal_xyz789", "status": "PENDING_USER_BIND", "registration_token": "reg_def456", "bind_url": "/bind?token=reg_def456" } ``` After registration, tell owner to open: ```text https://wallet.synapseai.pro/bind?token=reg_def456 ``` ### Technical Analysis The documentation identifies `registration_token` as the bearer credential used to authenticate wallet API requests, then places that same token in the binding URL's query string. Sensitive credentials in URLs can be retained or disclosed through browser history, copied links, screenshots, reverse-proxy and web-server access logs, monitoring or analytics systems, and potentially referrer metadata. The documentation does not establish that the URL token is a distinct credential, that it is single-use or short-lived, that it has restricted binding-only scope, or that it is immediately invalidated after binding. Consequently, compromise of the binding URL may expose a credential accepted by the documented authenticated endpoints. ### Attack Path 1. An agent registers a wallet and receives a `registration_token`. 2. The agent sends the owner a binding URL containing that token as a query parameter. 3. The owner opens or shares the URL, causing it to be stored or processed by a browser, intermediary, access log, analytics platform, screenshot, or communication history. 4. An attacker obtains the complete URL from one of those sources. 5. The attacker extracts the `token` query value. 6. The attacker submits that value as an `Authorization: Bearer` credential to the documented wallet endpoints. 7. If ...[truncated 799 chars]
- Remediation
- ## Remediation Suggestions 1. Generate a distinct binding credential that cannot authenticate wallet API requests. 2. Make the binding credential cryptographically random, narrowly scoped, short-lived, and single-use. 3. Exchange the binding credential through a POST request rather than exposing a reusable bearer credential in a URL query parameter. 4. Invalidate the binding credential immediately after successful use or expiration. 5. Rotate the API registration credential after owner binding so any previously exposed value becomes unusable. 6. Redact sensitive query parameters from application, proxy, CDN, monitoring, and analytics logs. 7. Apply a restrictive `Referrer-Policy`, such as `no-referrer`, to binding pages. 8. Prevent third-party resources from loading on pages while a sensitive binding value is present. 9. Document the credential separation, expiration period, scope, replay protections, and post-binding invalidation behavior. 10. Continue enforcing transaction limits, daily limits, merchant allowlists, and owner approval independently of possession of the bearer token.