T09 · Insecure Skill Coding Practices
Error
- Location
- references/integration-patterns.md:15
- Finding
- Externally Supplied Transactions Are Signed Without Documented Instruction Validation<![CDATA[ ## Vulnerability Details **File Location**: `references/integration-patterns.md`, lines 15-20 and 54-76 **Vulnerability Type**: Blind signing of untrusted serialized transactions **Risk Level**: High The integration pattern directs applications to retrieve a base64-encoded transaction from DFlow, deserialize it, sign it with the user's keypair, and submit it to Helius Sender. ```typescript const quoteRes = await fetch(`${DFLOW_API}/order?${params}`); const txBuffer = Buffer.from(quote.transaction, 'base64'); const sendRes = await fetch(SENDER_URL, { // ... params: [ Buffer.from(transaction.serialize()).toString('base64'), { encoding: 'base64', skipPreflight: true, maxRetries: 0 } ] }); ``` The documented flow at lines 15-20 explicitly describes the intervening steps as deserializing and signing the returned transaction. The same requirement is repeated in `references/dflow-spot-trading.md` around lines 57-58: ```text 2. Deserialize and sign the returned base64 transaction ``` ### Technical Analysis A serialized Solana transaction returned by a remote API is an untrusted authorization request. Signing it gives cryptographic authority to every instruction contained in the transaction. The guidance does not require the client to inspect or constrain: - Program IDs invoked by the transaction. - Source and destination token accounts. - SOL or token transfer recipients. - Transfer amounts and quoted minimum output. - Fee payer and required signers. - Address lookup tables and resolved account keys. - Compute-budget instructions or Jito tip recipients. - Whether the transaction corresponds to the quote displayed to the user. - Whether unexpected account-closing, delegate, approval, or authority-change instructions are present. TLS reduces ordinary network tampering but does not protect against a compromised DFlow service, compromised backend proxy, malicious application configuration, or a logic error that associates one user's quote w ...[truncated 1717 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Treat every transaction returned by DFlow as untrusted until validated. - Deserialize the transaction and resolve all static and address-lookup-table account keys before signing. - Allowlist expected program IDs, including the System Program, SPL Token programs, approved DFlow programs, Compute Budget Program, and any explicitly required associated-token programs. - Reject unexpected transfer, delegate, authority-change, account-close, or arbitrary program instructions. - Verify the fee payer, required signers, input mint, output mint, source owner, destination owner, transfer amount, minimum output, slippage, platform-fee account, and Jito tip account against independently constructed expectations. - Bind the returned transaction to the exact quote and user request shown for approval. - Display a human-readable transaction summary and obtain explicit user confirmation immediately before signing. - Prefer wallet-adapter signing over loading private key material into application code. - Simulate the validated transaction and reject simulation errors or unexpected balance changes. - Keep submission and signing separate: the backend may obtain a quote, but signing should remain under direct user control. - Do not rely on TLS, Sender, or simulation as substitutes for semantic instruction validation. ]]>