DApps - Gedesentraliseerde Toepassings

Wat is 'n DApp?

'n DApp is 'n gedesentraliseerde toepassing wat op 'n peer-to-peer netwerk loop, eerder as om op 'n gesentraliseerde bediener gehos te word. DApps is tipies gebou op blockchain tegnologie, wat moet toelaat dat daar deursigtigheid, sekuriteit en onveranderlikheid van data is.

Web3 DApp Argitektuur

Volgens hierdie pos is daar 3 verskillende tipes Web3 DApps argitektuur:

"API-loos" DApps

Hierdie DApps is gebou op 'n blockchain en staat nie op enige gesentraliseerde API's of agtergrond nie. Jy kan dink dat die blockchain die werklike agtergrond van die toepassing is. Hulle is volledig gedesentraliseerd en kan direk deur die blockchain toegang verkry.

Om met die blockchain te kommunikeer, sal die kliënt gewoonlik 'n wallet gebruik. Die wallet sal die transaksies teken en dit na die blockchain stuur. Die kliënt kan ook 'n node gebruik om data van die blockchain te lees.

"API-Gemagtigde" DApps

Hierdie DApps is gebou op 'n blockchain maar staat ook op gesentraliseerde API's, gewoonlik om inligting te versamel. Hulle is meestal gedesentraliseerd omdat selfs al staat hulle op 'n gesentraliseerde API, die kernfunksionaliteit van die DApp steeds op die blockchain is. Die kommunikasie van die kliënt met die blockchain word gewoonlik deur 'n wallet gedoen.

'n Goeie voorbeeld van hierdie tipe DApp is 'n NFT minting toepassing. Die bediener laat toe om die beelde op te laai, maar die minting word deur die kliënt deur 'n wallet gedoen.

"Volle Skaal" DApps

Hierdie DApps is gebou op 'n blockchain maar staat ook op gesentraliseerde API's en agtergrond bedieners. Hulle kan gedeeltelik gedesentraliseerd wees aangesien die kliënt dalk in staat is om operasies op die blockchain uit te voer met 'n wallet. Tog, gewoonlik kan die agtergrond ook operasies op die blockchain uitvoer.

'n Goeie voorbeeld van hierdie tipe DApp is 'n kruis-ketting brug waar 'n offchain komponent nodig is om met beide slim kontrakte in verskillende blockchains te kommunikeer om die oordrag van bates uit te voer.

Web2 kwesbaarhede

Web2 kwesbaarhede beïnvloed steeds hierdie soort toepassings al kan hul impak verskil:

• Kliënt kant kwesbaarhede het 'n verhoogde impak aangesien in die Web3 DApps die kliënt gewoonlik die een is wat die operasies op die blockchain uitvoer deur 'n wallet. Dit beteken dat aanvalle soos XSS wat daarin slaag om JS kode aan die kliënt kant uit te voer of wat met die inhoud van die bladsy tamper, 'n groter impak kan hê aangesien hulle kan interaksie hê met die wallet en die gebruiker kan oortuig om ongewenste operasies op die blockchain uit te voer.
• Let daarop dat gewoonlik selfs in hierdie soort toepassings die kliënt steeds die operasies kan hersien voordat hulle dit met die wallet teken. As die aanvaller egter in staat is om met die inhoud van die bladsy te tamper, kan dit die gebruiker oortuig om 'n transaksie te teken wat 'n ongewenste operasie op die blockchain sal uitvoer.
• Bediener kant kwesbaarhede is steeds teenwoordig in die DApps wat op 'n agtergrond bediener staat. Die impak van hierdie kwesbaarhede sal afhang van die argitektuur van die DApp. Dit kan egter steeds baie problematies wees aangesien 'n aanvaller dalk in die agtergrond sleutels van die maatskappy kan vind om toegang tot die fondse van slim kontrakte te verkry, of kan rekening oorname uitvoer wat hulle in staat stel om fondse of NFTs van die gebruikers te steel.

Natuurlik, as die DApp nie 'n agtergrond gebruik nie of die agtergrond wat gebruik word slegs openbare kettingdata of statiese bladsye bied, word die aanvaloppervlak van die DApp verminder.

Web3 aanvaloppervlak

Alhoewel 'n DApp in die algemeen 'n verminderde aanvaloppervlak het aangesien verskeie sekuriteitskontroles altyd op die blockchain gedoen word, is daar steeds 'n paar aanvalsvectors wat deur 'n aanvaller uitgebuit kan word.

Dit mag moontlik wees om web3 DApps kwesbaarhede in die volgende kategorieë te groepeer:

• Sleg hanteerde On-Chain Transaksies: verkeerd geformateerde of onbeperkte transaksie API's, gebrek aan antwoord-wag en blok-bevestiging logika, blootstelling van sensitiewe data, en onvanpaste hantering van mislukte, teruggetrokke, of intern-ge tipeerde transaksies wat kwaadwillige calldata-inspuitings toelaat.

• Slim-Kontrak-gedrewe Agtergrond Aanvalle: stoor of sink sensitiewe data tussen kontrakte en databasisse sonder validasie, ongekontroleerde gebeurtenis-emissies of kontrak adresse, en uitbuitbare kontrak kwesbaarhede wat agtergrond logika kan vergiftig.

• Foutiewe Crypto-Bates Operasies: verkeerde verwerking van verskillende token tipes (natuurlik vs. ERC-20), ignoreer desimale presisie, mislukte oordragte of interne transaksies, en die aanvaarding van vals, deflasionêre, herbasering, of slippage-gevoelige tokens sonder validasie, wat payload inspuitings via token metadata moontlik maak.

Sommige voorbeelde uit hierdie pos:

Vermorsing van Fondse: Dwing agtergrond om transaksies uit te voer

In die scenario Vermorsde Crypto in Gas via Onbeperkte API, kan die aanvaller die agtergrond dwing om funksies van 'n slim kontrak aan te roep wat gas sal verbruik. Die aanvaller, wat net 'n ETH rekeningnommer stuur en sonder enige beperkings, sal die agtergrond dwing om die slim kontrak aan te roep om dit te registreer, wat gas sal verbruik.

DoS: Swak transaksie hantering tyd

In die scenario Swak Transaksie Tyd Hantering Lei tot DoS, word verduidelik dat omdat die agtergrond die HTTP versoek oop sal hou totdat 'n transaksie uitgevoer word, 'n gebruiker maklik verskeie HTTP versoeke na die agtergrond kan stuur, wat al die hulpbronne van die agtergrond sal verbruik en tot 'n DoS sal lei.

Agtergrond<-->Blockchain desinkronisasie - Wedlooptoestand

In die scenario Swak Transaksie Tyd Hantering Lei tot Wedlooptoestand, word verduidelik dat in 'n speletjie dit moontlik was vir die gebruiker om 'n onttrekkingsversoek na die agtergrond te stuur wat die gebruiker sy munte sal stuur, maar terwyl die transaksie steeds verwerk is, kon die gebruiker daardie munte gebruik om items in die speletjie aan te koop, en dit gratis kry.

'n Ander voorbeeld kan wees om dieselfde munte te gebruik om verskillende items aan te koop aangesien die agtergrond onmiddellik die item aan die gebruiker gee sonder om te wag vir die transaksie om bevestig te word en dus te wag vir die gebruiker se balans in die blockchain om verminder te word.

Slim kontrak adres validasie

In die scenario Brug Agtergrond Ontbreek Slim Kontrak Adres Validasie word verduidelik hoe die agtergrond die adres van die slim kontrak nagegaan het, sodat dit moontlik was vir 'n aanvaller om 'n vals slim kontrak te ontplooi, fondse daarop te plaas, die transaksie na die agtergrond te stuur en die agtergrond sal dink dat die gebruiker fondse na die werklike slim kontrak gestuur het en die gebruiker die tokens sal gee.

Sleg hanteer van Batesklasse

In die scenario Sleg hanteer van Batesklasse, word verduidelik dat die agtergrond 'n scam NFT in 'n adres met 1 MATIC verwar het, wat die aanvaller in staat gestel het om honderde scam NFTs na die adres te stuur en 1 MATIC van die platform vir elkeen van hulle te kry.

Verwysings

• https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications