DApps - Decentralizovane Aplikacije

Reading time: 5 minutes

{{#include ../../banners/hacktricks-training.md}}

Šta je DApp?

DApp je decentralizovana aplikacija koja radi na peer-to-peer mreži, umesto da bude hostovana na centralizovanom serveru. DApps su obično izgrađene na blockchain tehnologiji, koja bi trebala da omogući transparentnost, sigurnost i nepromenljivost podataka.

Web3 DApp Arhitektura

Prema ovom postu, postoje 3 različite vrste Web3 DApp arhitekture:

"API-less" DApps

Ove DApps su izgrađene na vrhu blockchain-a i ne oslanjaju se na bilo kakve centralizovane API-je ili backend. Možete pomisliti da je blockchain zapravo backend aplikacije. One su potpuno decentralizovane i mogu se pristupiti direktno kroz blockchain.

Da bi interagovao sa blockchain-om, klijent obično koristi novčanik. Novčanik će potpisati transakcije i poslati ih na blockchain. Klijent takođe može koristiti čvor za čitanje podataka sa blockchain-a.

"API-Enabled" DApps

Ove DApps su izgrađene na vrhu blockchain-a, ali se takođe oslanjaju na centralizovane API-je obično za prikupljanje informacija. One su većinom decentralizovane jer, čak i ako se oslanjaju na centralizovani API, osnovna funkcionalnost DApp-a je još uvek na blockchain-u. Komunikacija klijenta sa blockchain-om obično se vrši putem novčanika.

Dobar primer ove vrste DApp-a je NFT minting aplikacija. Server omogućava upload slika, ali minting se vrši od strane klijenta putem novčanika.

"Full-Scale" DApps

Ove DApps su izgrađene na vrhu blockchain-a, ali se takođe oslanjaju na centralizovane API-je i backend servere. One mogu biti delimično decentralizovane jer klijent može da izvrši operacije na blockchain-u koristeći novčanik. Međutim, obično backend takođe može da izvrši operacije na blockchain-u.

Dobar primer za ovu vrstu DApp-a je cross-chain most gde je potrebna offchain komponenta da komunicira sa pametnim ugovorima u različitim blockchain-ima kako bi izvršila transfer sredstava.

Web2 ranjivosti

Web2 ranjivosti i dalje utiču na ove vrste aplikacija, iako njihov uticaj može varirati:

• Ranjivosti na klijentskoj strani imaju povećan uticaj jer u Web3 DApps klijent obično izvodi operacije na blockchain-u putem novčanika. To znači da napadi poput XSS koji uspeju da izvrše JS kod na klijentskoj strani ili koji manipulišu sadržajem stranice mogu imati veći uticaj jer mogu interagovati sa novčanikom i ubediti korisnika da izvrši neželjene operacije na blockchain-u.
• Imajte na umu da obično čak i u ovim vrstama aplikacija klijent može pregledati operacije pre nego što ih potpiše novčanikom. Međutim, ako napadač uspe da manipuliše sadržajem stranice, može ubediti korisnika da potpiše transakciju koja će izvršiti neželjenu operaciju na blockchain-u.
• Ranjivosti na serverskoj strani su i dalje prisutne u DApps koje se oslanjaju na backend server. Uticaj ovih ranjivosti zavisiće od arhitekture DApp-a. Međutim, one bi i dalje mogle biti veoma problematične jer bi napadač mogao pronaći u backend-u ključeve kompanije za pristup sredstvima pametnih ugovora, ili bi mogao izvršiti preuzimanje naloga koje bi im omogućilo da ukradu sredstva ili NFT-ove od korisnika.

Naravno, ako DApp ne koristi backend ili backend koji se koristi nudi samo javne podatke ili statične stranice, površina napada DApp-a je smanjena.

Web3 površina napada

Čak i ako generalno DApp ima smanjenu površinu napada jer se na blockchain-u uvek vrše različite sigurnosne provere, i dalje postoje neki vektori napada koje napadač može iskoristiti.

Moguće je grupisati ranjivosti web3 DApps u sledeće kategorije:

• Loše upravljanje On-Chain Transakcijama: nepravilno formatirani ili neograničeni API-ji za transakcije, nedostatak logike čekanja na odgovor i potvrdu blokova, izlaganje osetljivih podataka i nepravilno rukovanje neuspelim, vraćenim ili interno tipizovanim transakcijama koje omogućavaju zlonamerne injekcije podataka.

• Napadi vođeni pametnim ugovorima: čuvanje ili sinhronizacija osetljivih podataka između ugovora i baza podataka bez validacije, neproverene emisije događaja ili adrese ugovora, i ranjivosti ugovora koje se mogu iskoristiti i koje mogu otrovati logiku backend-a.

• Pogrešne operacije sa kripto-sredstvima: pogrešno procesuiranje različitih tipova tokena (nativni vs. ERC-20), ignorisanje decimalne preciznosti, neuspešni transferi ili interne transakcije, i prihvatanje lažnih, deflacionarnih, rebase ili sklizak tokena bez validacije, omogućavajući injekcije podataka putem metapodataka tokena.

Neki primeri iz ovog posta:

Bacanje sredstava: Prisiljavanje backend-a da izvrši transakcije

U scenariju Wasted Crypto in Gas via Unrestricted API, napadač može prisiliti backend da pozove funkcije pametnog ugovora koje će trošiti gas. Napadač, samo šaljući ETH broj računa i bez ograničenja, prisiliće backend da pozove pametni ugovor da ga registruje, što će trošiti gas.

DoS: Loše vreme obrade transakcija

U scenariju Poor Transaction Time Handling Leads to DoS, objašnjeno je da, pošto će backend držati HTTP zahtev otvorenim dok se transakcija ne izvrši, korisnik može lako poslati nekoliko HTTP zahteva backend-u, što će potrošiti sve resurse backend-a i dovesti do DoS.

Backend<-->Blockchain desinkronizacija - Uslovni trka

U scenariju Poor Transaction Time Handling Leads to Race Condition, objašnjeno je da je u igri bilo moguće da korisnik pošalje zahtev za povlačenje backend-u koji će poslati korisniku njegove novčiće, ali dok je transakcija još uvek bila u obradi, korisnik je mogao da koristi te novčiće za kupovinu predmeta u igri, dobijajući ih besplatno.

Još jedan primer bi mogao biti mogućnost korišćenja istih novčića za kupovinu različitih predmeta jer backend odmah daje predmet korisniku bez čekanja na potvrdu transakcije i stoga ne čekajući da se saldo korisnika na blockchain-u smanji.

Validacija adrese pametnog ugovora

U scenariju Bridge Backend Lacks Smart Contract Address Validation objašnjeno je kako je backend proveravao adresu pametnog ugovora, tako da je napadač mogao da postavi lažni pametni ugovor, stavi sredstva na njega, pošalje transakciju backend-u i backend će pomisliti da je korisnik poslao sredstva pravom pametnom ugovoru i dodeliće korisniku tokene.

Loše upravljanje klasama sredstava

U scenariju Mishandling of Asset Classes, objašnjeno je da je backend pomešao prevarantski NFT na adresi sa 1 MATIC, omogućavajući napadaču da pošalje stotine prevarantskih NFT-ova na adresu i dobije 1 MATIC od platforme za svaki od njih.

Reference

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

{{#include ../../banners/hacktricks-training.md}}