Le falle di x402 SDK mettono a rischio wallet, pagamenti e login
Le falle di x402 SDK divulgate dalla società di sicurezza V12 hanno esposto tre rischi distinti relativi alla spesa automatizzata dei wallet, alla verifica dei pagamenti e ai login ai siti web. Durante una revisione del codice e test locali, V12 ha individuato 25 falle, classificandone tre come critiche. La x402 Foundation, che mantiene i kit di sviluppo software (SDK), le ha corrette tutte e tre nei rilasci pubblicati il 18 agosto. Né V12 né la fondazione hanno segnalato pubblicamente attacchi che le abbiano sfruttate.
x402 è uno standard aperto che consente ai software, compresi gli agent di intelligenza artificiale, di pagare una richiesta a un'interfaccia di programmazione delle applicazioni (API) senza attendere che una persona approvi ogni transazione. Un server richiede il pagamento restituendo HTTP status code 402 Payment Required, insieme a opzioni che specificano un importo, un asset digitale e un destinatario. Il client seleziona un'opzione, firma il pagamento e ripete la richiesta allegando il pagamento.
Prima delle correzioni, il client predefinito selezionava la prima opzione di pagamento senza imporre un importo massimo. Secondo V12, un'API malevola poteva richiedere l'intero saldo del wallet in un asset digitale supportato, anziché un piccolo pagamento ordinario. Una transazione precedente poteva rivelare l'indirizzo del wallet, consentendo al server di controllare il saldo disponibile. Se un'applicazione firmava automaticamente i pagamenti e non aveva configurato restrizioni proprie, il client poteva approvare l'intero importo. Per gli asset che supportano transfer firmati, il server malevolo poteva quindi inviare il pagamento e ricevere i fondi. Il rischio era limitato alle implementazioni che utilizzavano la firma automatica senza limiti a livello di applicazione.
I rilasci TypeScript, Python e Go del 18 agosto hanno introdotto controlli di spesa predefiniti. Ogni pagamento è ora limitato a $1 e i client pagheranno soltanto in stablecoin riconosciute ancorate al dollaro statunitense, tra cui USDC, a meno che l'applicazione non definisca controlli diversi. Una stablecoin è un asset digitale progettato per seguire il valore di un altro asset, in questo caso il dollaro statunitense. Le applicazioni che impostano esplicitamente spendControls: false disabilitano tutte queste protezioni.
Una seconda falla critica interessava la verifica dei pagamenti Solana nell'SDK TypeScript. In x402, un facilitator verifica il pagamento di un commerciante e lo invia alla blockchain, il registro condiviso delle transazioni utilizzato dalla rete. Su Solana, il facilitator copre anche la commissione della transazione. Il codice vulnerabile confermava che un pagamento chiamasse un token program consentito, ma non verificava l'instruction type prima di interpretare l'instruction come un transfer.
Un token approval autorizza un altro account a spendere asset in un secondo momento, ma non trasferisce immediatamente nulla. Si distingue da un transfer per il primo byte dell'instruction. Durante un test locale, V12 ha scoperto che il facilitator TypeScript accettava un token approval come se fosse un pagamento completato. Il test non ha inviato una transazione live. Di conseguenza, un commerciante poteva rendere disponibile una risorsa a pagamento senza ricevere fondi, mentre il facilitator pagava la commissione. Il richiedente doveva disporre di un token account, ma non era necessario che avesse un saldo. Python e Go verificavano già l'instruction type e il rilascio TypeScript del 18 agosto ha aggiunto la validazione mancante. The Hacker News ha rilevato che le versioni da 2.0.0 a 2.22.0 di @x402/svm non disponevano del controllo, mentre i rilasci dalla versione 2.23.0 in poi lo includono.
Il terzo problema critico riguardava Sign-In-With-X (SIWx), un'estensione di x402 che consente a un agent di dimostrare il controllo di un wallet firmando un messaggio di login. Su Ethereum, tale messaggio identifica un sito web, un indirizzo di wallet e un codice monouso. Il client automatizzato non verificava che il sito web indicato nel messaggio corrispondesse al server che aveva inviato la risposta di pagamento. V12 ha affermato che un server malevolo poteva effettuare il relay di un messaggio recente proveniente da un altro sito web, ottenere la firma dell'agent e utilizzarla per accedere all'altro sito ovunque il messaggio inoltrato fosse accettato. L'accesso risultante dipendeva dalle autorizzazioni concesse dal login.
I client TypeScript, Python e Go aggiornati rifiutano di firmare quando il sito web nel messaggio SIWx è diverso dal sito che ha restituito la risposta 402. Ora anche la specifica SIWx richiede lo stesso controllo. Le applicazioni TypeScript che chiamano direttamente createSIWxPayload devono fornire l'URL della risposta 402 dopo i redirect. I wrapper @x402/fetch e @x402/axios forniscono automaticamente tale URL.
Nonostante la gravità assegnata da V12, la fondazione non ha pubblicato alcun security advisory per questi tre problemi e i suoi changelog hanno registrato le modifiche senza identificarle come correzioni di sicurezza. Al 23 ottobre, The Hacker News non aveva trovato alcun npm audit advisory per gli ultimi rilasci TypeScript vulnerabili, né alcuna voce relativa alla vulnerabilità su PyPI per l'ultimo rilascio Python vulnerabile. Gli sviluppatori che si fossero affidati soltanto a tali controlli dei package non avrebbero quindi ricevuto alcun avviso di aggiornamento. Coinbase ha creato x402 e quest'anno lo ha trasferito alla x402 Foundation, un progetto della Linux Foundation i cui membri includono Visa e Mastercard. Coinbase ricopre la posizione di maggior rilievo nel suo comitato direttivo tecnico.
I team dovrebbero installare i rilasci attuali anziché fermarsi alle prime versioni corrette, perché gli aggiornamenti successivi includono una correzione separata, pubblicata a settembre, per un payment bypass in @x402/core 2.27.0. Al 23 ottobre, le versioni TypeScript più recenti erano la 2.28.0 per @x402/core, @x402/svm, @x402/extensions, @x402/fetch e @x402/axios. Il modulo Go più recente era v2.28.0, mentre il package Python era alla versione 2.25.0. I client TypeScript ricevono la correzione dei controlli di spesa tramite @x402/fetch o @x402/axios 2.23.0 o versioni successive. Gli utenti SIWx necessitano di @x402/extensions 2.23.0 o versioni successive, mentre i facilitator Solana necessitano di @x402/svm 2.23.0 o versioni successive.
I team che non possono effettuare subito l'aggiornamento possono configurare una policy di pagamento che rifiuti le opzioni superiori a un importo prescelto. I client meno recenti supportano registerPolicy in TypeScript e Go, mentre Python offre register_policy e una policy max_amount già pronta. V12 raccomanda inoltre di controllare il sito web identificato in ogni messaggio SIWx, impostare budget per singolo pagamento e budget complessivi e limitare gli asset, le reti e i destinatari consentiti. I team che necessitano di assistenza per pianificare interventi infrastrutturali incentrati sulla sicurezza possono rivolgersi ad AEU-I per servizi IT, infrastruttura e consulenza security-first.