T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/hire.js:50
- Finding
- Escrow Payment Is Released Without Validating Provider Output<![CDATA[ ## Vulnerability Details **File Location**: `scripts/hire.js:50-89` **Vulnerability Type**: Automatic authorization of untrusted marketplace output **Risk Level**: High ### Vulnerable Code ```js if (status === 1 || status === 2) { // Status 1 = Submitted (need to confirm) // Status 2 = Already completed if (status === 1) { console.log("\nProvider delivered! Confirming + rating..."); try { await new Promise(r => setTimeout(r, 3000)); const cNonce = await wallet.getNonce("pending"); const confirmTx = await escrow.confirmComplete(jobId, { nonce: cNonce }); await confirmTx.wait(); console.log("Payment released!"); await new Promise(r => setTimeout(r, 3000)); const rNonce = await wallet.getNonce("pending"); const rateTx = await escrow.rateJob(jobId, 5, { nonce: rNonce }); await rateTx.wait(); console.log("Rated 5/5 stars."); } catch (e) { console.log("Auto-completed by provider."); } } else { console.log("\nJob completed!"); } // Parse result try { const r = JSON.parse(result); if (r.success) { console.log(`\nResult: Swapped ${r.amountIn} ${r.fromToken} → ${r.amountOut} ${r.toToken}`); console.log(`TX Hash: ${r.txHash}`); if (r.basescanUrl) console.log(`Verify: ${r.basescanUrl}`); console.log(`DEX: ${r.dex}`); } else { console.log(`\nJob failed: ${r.error}`); } } catch { console.log(`\nResult: ${result}`); } process.exit(0); } ``` ### Technical Analysis A provider-controlled state transition to status `1` (“Submitted”) is treated as sufficient proof that the task was completed correctly. The script calls `confirmComplete()` before parsing or validating the result. This releases the escrow payment even when the result is empty, malformed, unrel ...[truncated 1699 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Parse and validate the provider result before calling `confirmComplete()`. 2. Require explicit user approval before releasing escrow, especially for financial or externally verifiable tasks. 3. Define task-specific result schemas and reject missing, malformed, or contradictory fields. 4. For on-chain work, independently query the configured chain and verify the transaction hash, sender, recipient, token addresses, amounts, status, and expected state changes. 5. Use cryptographic commitments or signed provider responses where the marketplace protocol supports them. 6. Award a rating only after successful verification and user approval; never submit a fixed five-star rating. 7. Separate confirmation and rating exception handlers, preserve the actual error, and do not report a failed transaction as an automatic completion. 8. Provide a dispute, cancellation, or manual-review workflow when validation cannot establish correctness. ]]>