T09 · Insecure Skill Coding Practices
Error
- Location
- references/token-server/README.md:46
- Finding
- Unauthenticated and Over-Privileged RTC Token Issuance<![CDATA[ ## Vulnerability Details **File Location**: `references/token-server/README.md`, lines 46–77 and 109–113 **Vulnerability Type**: Missing endpoint authentication and excessive token privileges **Risk Level**: High ### Vulnerable Code ```markdown ### Step 3: Implement Token Endpoint Create a `GET /api/agora/token` endpoint. **Request parameters:** | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| | `channelName` | string | Yes | — | RTC channel name. `""` for wildcard (any channel). | | `uid` | integer | No | `0` | User ID. `0` = wildcard (any user). | | `role` | string | No | `publisher` | `publisher` (send+receive) or `subscriber` (receive only) | | `expireSeconds` | integer | No | `3600` | Token validity in seconds. Max: 86400 (24h). | **Response:** Plain text token string. | Status | Meaning | |--------|---------| | 200 | Token generated | | 400 | Missing `channelName` | | 500 | Generation failed | **Example:** ```bash curl "http://localhost:8080/api/agora/token?channelName=test&uid=12345&role=publisher&expireSeconds=3600" ``` ``` ```markdown ### Wildcard Tokens - `uid = 0` → works for any UID - `channelName = ""` → works for any channel - Both wildcard → single token for any user in any channel (use with caution) ``` ### Technical Analysis The generated token-server specification does not require callers to authenticate before obtaining a signed RTC token. It also allows caller-controlled channel names, UIDs, roles, and expiration periods. The default role is `publisher`, which grants send and receive capabilities. The documented wildcard behavior permits tokens valid for arbitrary users or channels. Although the text says to use wildcard tokens with caution, it does not require privileged authorization or disable this behavior by default. The token endpoint therefore acts as an unrestricted signing oracle if it is deployed where an attacker can reach it. The App Certifica ...[truncated 1277 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require application-level authentication before issuing any token. 2. Authorize each request against the authenticated user's permitted channels and capabilities. 3. Derive the UID, channel, and role from trusted server-side session state instead of accepting unrestricted client-selected values. 4. Default to subscriber or the minimum necessary privileges rather than publisher. 5. Disable empty-channel and wildcard-UID tokens by default. 6. Place wildcard issuance behind a separate administrative authorization path if it is operationally necessary. 7. Use fine-grained privilege tokens and grant only required capabilities such as channel join, audio publication, video publication, or data-stream publication. 8. Enforce a short server-controlled expiration limit instead of trusting the requested value. 9. Apply rate limiting, abuse monitoring, restrictive CORS rules, and security audit logging. 10. Prefer an authenticated `POST` endpoint and return tokens with `Cache-Control: no-store`. 11. Update the Skill guidance so generated implementations must include these controls rather than leaving them as optional production hardening. ]]>