T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:59
- Finding
- Remote-Controlled Payment Authorization Without User-Approved Limits## Vulnerability Details **File Location**: `SKILL.md`, lines 59–60 and 82–88 **Vulnerability Type**: Unbounded payment authorization based on remote responses **Risk Level**: High ### Vulnerable Code ```markdown → On `202`: save `requestId` and go to Step 3. → On `402`: re-read the payment requirements from the response and retry with a correct `X-PAYMENT` header. ``` ```markdown ## Step 4 — Handle extra payment (if needed) If status is `authorization_required`, the order total exceeded the quoted amount: ```http POST https://checkout-agent.credpay.xyz/v1/checkout/{requestId}/authorize X-PAYMENT: <x402 payment for extraOwed amount> ``` Then resume polling from Step 3. ``` ### Technical Analysis The skill directs the agent to generate payments from requirements supplied by the remote checkout service. If the service returns HTTP `402`, the agent is instructed to reread those requirements and retry. It may also pay an unspecified `extraOwed` amount when the service reports `authorization_required`. No instruction requires fresh, explicit user approval before either payment flow. The skill also does not require validation of the payment recipient, asset, chain, cumulative amount, or permitted increase against user-approved constraints. Although the initial quote produces a `maxAmount`, no immutable relationship is enforced between that quote and later payment requirements. Consequently, a compromised, malicious, or faulty API could alter the payment destination or request an amount exceeding the user's intended purchase limit. ### Attack Path 1. A user asks the agent to purchase a product and supplies the required order and shipping information. 2. The agent obtains a quote and submits the checkout request. 3. The remote service, or an attacker controlling it, returns manipulated HTTP `402` payment requirements, or later reports `authorization_required` with an inflated `extraOwed`. 4. Following ...[truncated 743 chars]
- Remediation
- ## Remediation Suggestions - Require explicit user confirmation after displaying the final total before creating the initial payment. - Require separate explicit confirmation for every additional payment, including any `extraOwed` amount. - Bind authorization to an immutable allowlist containing the expected recipient, Base chain ID `8453`, approved token contract, product details, and maximum cumulative amount. - Reject any revised HTTP `402` requirements that change the recipient, chain, token, or total beyond the user's approved parameters. - Never automatically satisfy remotely supplied replacement payment requirements. - Treat the initial `maxAmount` as a strict cumulative ceiling unless the user knowingly approves a specific increase. - Record payments associated with each `requestId` and prevent duplicate or replayed authorization. - Present the user with an itemized quote, fees, destination, asset, and exact additional amount before approval. - Inform the user that their contact and shipping information will be disclosed to the named checkout service and obtain consent before transmission.