T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:57
- Finding
- Unvalidated Server-Directed Cryptocurrency Payment## Vulnerability Details **File Location**: `SKILL.md`, lines 57–63; related automatic-invocation behavior is documented in `README.md`, line 21 **Vulnerability Type**: Unvalidated payment authorization **Risk Level**: Medium **Vulnerable Code Snippet**: ```markdown 1. Call the service endpoint without payment headers. 2. Receive HTTP 402 with `WWW-Authenticate: Payment` header AND x402 `accepts[]` array in response body. 3. Select a `paymentRequirement` from `accepts[]` matching your preferred network + asset. 4. Networks: `cardano:mainnet` (ADA, DJED, iUSD, USDCx, USDM), `stellar:pubnet` (USDC, XLM), `sandbox` (free). 5. Send payment to the `payTo` address for `maxAmountRequired` in the specified asset. 6. **Stellar fee sponsorship:** POST your signed XDR to `https://ai-service-hub-15.emergent.host/api/mpp/stellar/sponsor` — NEXUS pays gas, you need 0 XLM. 7. Retry with `X-PAYMENT: <base64url JSON {x402Version:1, scheme:"exact", network, payload:{tx_hash, currency}}>` header. ``` Related invocation behavior: ```markdown This skill is automatically invoked by your OpenClaw agent when a matching task is detected. ``` ### Technical Analysis The payment workflow instructs an agent to use the remote server's `payTo` and `maxAmountRequired` values without requiring independent validation against trusted local policy. Although the documentation advertises a price of `$0.25/request`, the workflow does not specify a locally enforced maximum, a pinned recipient address, an approved asset and network allowlist, challenge-expiration checks, replay protection, or mandatory user confirmation before payment. The same remote service also receives signed Stellar XDR data for fee sponsorship. A signed transaction should be treated as security-sensitive authorization material and must be verified locally to ensure that its operations, destination, asset, amount, memo, sequence number, and network match the user's intent before ...[truncated 2056 chars]
- Remediation
- ## Remediation Suggestions 1. Require explicit, transaction-specific user approval before constructing, signing, or submitting any paid transaction. Automatic skill selection must never imply payment consent. 2. Enforce a local maximum charge equal to the advertised price or a separately configured user budget. Reject missing, malformed, zero, negative, or excessive amounts. 3. Pin trusted recipient addresses locally for each supported chain and reject a challenge whose `payTo` value does not match the configured recipient. 4. Maintain explicit allowlists for supported networks, chain identifiers, assets, token issuers or policy IDs, and payment schemes. 5. Present the recipient, amount, fiat equivalent, asset, network, fees, and all transaction operations to the user before signing. 6. Fully decode and validate Stellar XDR before signing or submitting it. Confirm the network passphrase, source account, sequence number, time bounds, operation types, destination, amount, asset issuer, memo, and fee structure. 7. Bind each payment challenge to the intended request using an authenticated request identifier, nonce, expiration time, and server signature. Reject expired or replayed challenges and credentials. 8. Separate service discovery from payment authorization. Treat all HTTP 402 response fields as untrusted input even when received over TLS. 9. Apply per-request and cumulative spending limits at the wallet or signer layer so the skill cannot override them. 10. Document failure behavior explicitly: any recipient, amount, asset, network, or transaction mismatch must abort the operation without payment.