Dobësitë e x402 SDK vënë në rrezik wallet-et, pagesat dhe hyrjet
Dobësitë e x402 SDK, të zbuluara nga kompania e sigurisë V12, ekspozuan tri rreziqe të veçanta që lidhen me shpenzimet e automatizuara nga wallet, verifikimin e pagesave dhe hyrjet në faqe interneti. V12 gjeti 25 dobësi gjatë një code review dhe testimeve lokale, duke i vlerësuar tri prej tyre si kritike. x402 Foundation, që mirëmban paketat SDK, i korrigjoi të tria në release-et e publikuara më 18 gusht. As V12 dhe as fondacioni nuk kanë raportuar publikisht sulme që i kanë shfrytëzuar ato.
x402 është një standard i hapur që i lejon software-it, përfshirë agjentët e inteligjencës artificiale, të paguajë për një kërkesë application programming interface (API) pa pritur që një person të miratojë çdo transaksion. Një server kërkon pagesë duke kthyer HTTP status code 402 Payment Required, së bashku me opsione që përcaktojnë shumën, asetin digjital dhe marrësin. Client zgjedh një opsion, nënshkruan pagesën dhe e përsërit kërkesën me pagesën të bashkëngjitur.
Përpara korrigjimeve, client i parazgjedhur zgjidhte opsionin e parë të pagesës pa vendosur një shumë maksimale. Sipas V12, një API keqdashës mund të kërkonte të gjithë gjendjen e wallet për një aset digjital të mbështetur, në vend të një pagese të vogël rutinë. Një transaksion i mëparshëm mund të zbulonte adresën e wallet, duke i mundësuar server të kërkonte gjendjen e disponueshme. Nëse një aplikacion i nënshkruante automatikisht pagesat dhe nuk kishte konfiguruar kufizimet e veta, client mund të miratonte shumën e plotë. Për asetet që mbështesin signed transfers, server keqdashës mund ta dërgonte më pas atë pagesë dhe të merrte fondet. Rreziku kufizohej te implementimet që përdornin automatic signing pa kufizime në nivel aplikacioni.
Release-et e 18 gushtit për TypeScript, Python dhe Go prezantuan kontrolle të parazgjedhura të shpenzimeve. Çdo pagesë tani kufizohet në 1 dollar dhe client do të paguajë vetëm me asete stablecoin të njohura që ndjekin dollarin amerikan, përfshirë USDC, përveçse kur aplikacioni përcakton kontrolle të tjera. Një stablecoin është një aset digjital i krijuar për të ndjekur vlerën e një aseti tjetër, në këtë rast dollarin amerikan. Aplikacionet që vendosin shprehimisht spendControls: false i çaktivizojnë të gjitha këto masa mbrojtëse.
Një dobësi e dytë kritike prekte verifikimin e pagesave në Solana në SDK për TypeScript. Në x402, një facilitator kontrollon pagesën e një tregtari dhe e dërgon atë në blockchain, regjistri i përbashkët i transaksioneve që përdoret nga rrjeti. Në Solana, ai facilitator mbulon gjithashtu tarifën e transaksionit. Kodi i cenueshëm konfirmonte se një pagesë thërriste një token program të lejuar, por nuk verifikonte instruction type përpara se ta interpretonte instruction si transfer.
Një token approval autorizon një llogari tjetër që të shpenzojë asete më vonë, por nuk transferon asgjë menjëherë. Ai ndryshon nga një transfer në byte-in e parë të instruction. Në një test lokal, V12 zbuloi se facilitator për TypeScript pranonte një approval sikur të ishte një pagesë e përfunduar. Testi nuk dërgoi një transaksion live. Si pasojë, një tregtar mund të jepte një burim me pagesë pa marrë fondet, ndërsa facilitator paguante tarifën. Kërkuesit i nevojitej një token account, por nuk i nevojitej gjendje. Python dhe Go e kontrollonin tashmë instruction type, ndërsa release për TypeScript i 18 gushtit shtoi validation që mungonte. The Hacker News zbuloi se versionet 2.0.0 deri në 2.22.0 të @x402/svm nuk e kishin këtë kontroll, ndërsa release-et nga 2.23.0 e më tej e përfshijnë atë.
Çështja e tretë kritike lidhej me Sign-In-With-X (SIWx), një extension i x402 që i lejon një agjenti të provojë kontrollin e një wallet duke nënshkruar një mesazh hyrjeje. Në Ethereum, ai mesazh identifikon një faqe interneti, adresën e wallet dhe një kod njëpërdorimësh. Client i automatizuar nuk verifikonte nëse faqja e internetit e përmendur në mesazh përputhej me server që kishte dërguar përgjigjen e pagesës. V12 tha se një server keqdashës mund të përcillte një mesazh të ri nga një faqe tjetër interneti, të merrte nënshkrimin e agjentit dhe ta përdorte për të hyrë në atë faqe tjetër kudo që pranohej mesazhi i përcjellë. Aksesi i përftuar do të varej nga ajo që autorizonte hyrja.
Client e përditësuar për TypeScript, Python dhe Go refuzojnë të nënshkruajnë kur faqja e internetit në mesazhin SIWx ndryshon nga faqja që ktheu përgjigjen 402. Specifikimi SIWx tani kërkon të njëjtin kontroll. Aplikacionet TypeScript që thërrasin drejtpërdrejt createSIWxPayload duhet të japin URL e përgjigjes 402 pas redirects. Wrapper-at @x402/fetch dhe @x402/axios e japin automatikisht atë URL.
Pavarësisht nivelit të rëndë të caktuar nga V12, fondacioni nuk publikoi një security advisory për këto tri çështje dhe changelog-et e tij i regjistruan ndryshimet pa i identifikuar si korrigjime sigurie. Deri më 23 tetor, The Hacker News nuk gjeti asnjë npm audit advisory për release-et e fundit të cenueshme të TypeScript dhe asnjë vulnerability entry në PyPI për release-in e fundit të cenueshëm të Python. Prandaj, zhvilluesit që mbështeteshin vetëm te këto kontrolle të package nuk do të merrnin asnjë paralajmërim për upgrade. Coinbase krijoi x402 dhe këtë vit ia transferoi x402 Foundation, një projekt i Linux Foundation, anëtarët e të cilit përfshijnë Visa dhe Mastercard. Coinbase mban pozicionin më të lartë në technical steering committee të tij.
Ekipet duhet të instalojnë release-et aktuale në vend që të ndalen te versionet e para të korrigjuara, sepse përditësimet e mëvonshme përfshijnë një korrigjim të veçantë të shtatorit për payment bypass në @x402/core 2.27.0. Deri më 23 tetor, versionet më të fundit të TypeScript ishin 2.28.0 për @x402/core, @x402/svm, @x402/extensions, @x402/fetch dhe @x402/axios. Moduli më i fundit Go ishte v2.28.0, ndërsa package më i fundit Python ishte 2.25.0. Client TypeScript e marrin korrigjimin e shpenzimeve përmes @x402/fetch ose @x402/axios 2.23.0 apo më të ri. Përdoruesve të SIWx u nevojitet @x402/extensions 2.23.0 ose më i ri, ndërsa komponentëve facilitator për Solana u nevojitet @x402/svm 2.23.0 ose më i ri.
Ekipet që nuk mund të bëjnë upgrade menjëherë mund të konfigurojnë një payment policy që refuzon opsionet mbi një shumë të zgjedhur. Client më të vjetër mbështesin registerPolicy në TypeScript dhe Go, ndërsa Python ofron register_policy dhe një policy të gatshme max_amount. V12 rekomandon gjithashtu kontrollimin e faqes së internetit të identifikuar në çdo mesazh SIWx, vendosjen e buxheteve për çdo pagesë dhe të buxhetit të përgjithshëm, si dhe kufizimin e aseteve, rrjeteve dhe marrësve të lejuar. Ekipet që kanë nevojë për ndihmë në planifikimin e punës infrastrukturore me fokus te siguria mund t'i drejtohen AEU-I për IT, infrastrukturë dhe konsulencë me sigurinë si përparësi.