T09 · Insecure Skill Coding Practices
Error
- Location
- skill.md:13
- Finding
- Client-Controlled Agent Identity Enables Rate-Limit Bypass## Vulnerability Details **File Location**: `skill.md`, lines 13-56 and line 432 **Vulnerability Type**: Client-controlled identity and ineffective rate limiting **Risk Level**: High **Vulnerable documentation excerpts:** ```markdown **No authentication required** - launches are rate-limited per agent. ``` ```markdown | `agentId` | string | ✅ Yes | Your agent/app identifier | ``` ```markdown ### **Rate Limited** ```json {"error": "Rate limit exceeded", "resetIn": 3600} ``` **Fix:** Wait 1 hour or use different agentId ``` ### Technical Analysis The documented token-launch endpoint performs a financially consequential operation without authentication. Its quota is described as being enforced per `agentId`, but `agentId` is supplied directly by the caller. There is no documented cryptographic signature, authenticated account, server-issued identifier, or other binding between this value and a verified principal. Consequently, the caller can replace the identifier whenever its quota is exhausted. The documentation explicitly recommends this behavior at line 432. A mutable, unverified request field cannot serve as a reliable security boundary for abuse prevention. ### Attack Path 1. Submit requests to `POST https://fourclaw.fun/api/launch` using an arbitrary `agentId`. 2. Launch tokens until the service returns a rate-limit response. 3. Replace `agentId` with another arbitrary value, as suggested by the documented workaround. 4. Repeat the requests under the new identifier. 5. Automate identifier rotation to evade the stated hourly and daily limits continuously. ### Impact Assessment An unauthenticated remote caller could evade the intended launch quotas and initiate excessive cryptocurrency token-launch jobs. This may permit resource exhaustion, spam or abuse of external blockchain launch infrastructure, circumvention of operational controls, and attribution of activity to arbitrary agent identifiers ...[truncated 270 chars]
- Remediation
- ## Remediation Suggestions 1. Require authentication before accepting token-launch requests. 2. Replace caller-selected identity as the quota boundary with a server-issued, immutable account or application identifier. 3. Bind each request to the authenticated principal using securely managed sessions, signed API credentials, or wallet-signature verification with nonce and expiration checks. 4. Enforce quotas server-side across multiple abuse signals, such as authenticated account, verified wallet, IP reputation, and global service limits. 5. Prevent identifier rotation from resetting quotas and detect coordinated creation of disposable identities. 6. Remove the instruction recommending a different `agentId` after rate limiting. Instead, instruct callers to wait for the documented reset period. 7. Add idempotency keys and duplicate-launch detection to prevent replayed or accidental launch requests. 8. Require explicit confirmation for each irreversible or financially consequential token launch. 9. Record tamper-resistant audit logs and alert on rapid identifier rotation, repeated quota exhaustion, and anomalous launch volume. 10. Return generic rate-limit errors that do not suggest bypass techniques.