T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:82
- Finding
- Unvalidated Execution of Remotely Supplied Blockchain Transactions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 82–86 and 177–190 **Vulnerability Type**: Missing validation and authorization controls for blockchain transaction payloads **Risk Level**: High ### Vulnerable Code ```text ## Transaction Flow 1. Call create-token-transaction or trade-token → returns { transactions: [...], metadata: {...} } 2. For each tx in array: POST /send-transaction { to: tx.to, data: tx.data, amount: tx.value || "0", chainSlug } 3. Wait 5s (or tx.transactionDelay) between each transaction ``` ```bash ### Send Transaction curl -s -X POST "https://api.tokenlayer.network/functions/v1/send-transaction" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $TOKENLAYER_API_KEY" \ -d '{ "to": "0x...", "amount": "0", "data": "0x...", "chainSlug": "base" }' | jq ``` ### Technical Analysis The Skill instructs the Agent to submit every blockchain transaction returned by the remote transaction-generation API. It does not require the Agent to decode or validate the destination address, calldata, native-token value, function selector, token approval amount, chain identity, or expected state changes before forwarding the transaction to `/send-transaction`. Although the usage guidelines require user approval before creating a token, they do not require a final confirmation covering the exact transaction payloads that will be executed. Consequently, the approved high-level operation can differ from the concrete on-chain calls returned by the remote service. The security boundary is especially important because blockchain transactions are generally irreversible. A compromised, malicious, or defective API could return a transaction that performs an unrelated transfer, grants an excessive token allowance, invokes an unauthorized contract function, or directs assets to an attacker-controlled address. ### Attack Path 1. The Agent requests a transaction batch from `/create-token-transaction` or ...[truncated 1474 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Decode every returned transaction before submission and display its destination, function name, parameters, transferred value, chain, and anticipated state changes. 2. Require explicit user confirmation for the final decoded transaction batch, rather than relying only on approval of the high-level token creation or trade request. 3. Verify the chain ID or chain slug against the chain explicitly selected by the user. 4. Maintain an allowlist of trusted contract addresses and expected function selectors for each supported operation. 5. Reject transactions containing unexpected destinations, function calls, native-token values, delegate calls, approval operations, or contract deployment instructions. 6. For token approvals, enforce exact or narrowly bounded allowances and reject unlimited approvals unless separately disclosed and explicitly authorized. 7. Apply per-transaction and cumulative spending limits based on the amount approved by the user. 8. Simulate each transaction before execution and compare balance changes, approvals, recipients, and contract interactions with the requested operation. 9. Verify that all transactions in a batch are necessary and execute them sequentially only after the preceding receipt succeeds. 10. Stop processing immediately if a transaction fails validation or if the remote response differs from the user-approved intent. 11. Record validated transaction hashes and decoded details for auditability without logging the bearer API key. ]]>