hacktricks/src/pentesting-web/dapps-DecentralizedApplications.md

# DApps - Aplikacje Zdecentralizowane

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

## Czym jest DApp?

DApp to zdecentralizowana aplikacja, która działa w sieci peer-to-peer, zamiast być hostowana na scentralizowanym serwerze. DApps są zazwyczaj budowane na **technologii blockchain**, co powinno umożliwiać przejrzystość, bezpieczeństwo i niezmienność danych.

## Architektura DApp Web3

Zgodnie z [**tym postem**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications) istnieją 3 różne typy architektury DApps Web3:

### DApps "bez API"

Te DApps są budowane na blockchainie i nie polegają na żadnych scentralizowanych API ani backendzie. Można pomyśleć, że blockchain jest rzeczywistym backendem aplikacji. Są **w pełni zdecentralizowane** i można je uzyskać bezpośrednio przez blockchain.

Aby interagować z blockchainem, klient zazwyczaj używa **portfela**. Portfel podpisuje transakcje i wysyła je do blockchaina. Klient może również używać **węzła** do odczytu danych z blockchaina.

### DApps "z API"

Te DApps są budowane na blockchainie, ale również polegają na scentralizowanych API, zazwyczaj w celu zbierania informacji. Są **głównie zdecentralizowane**, ponieważ nawet jeśli polegają na scentralizowanym API, podstawowa funkcjonalność DApp nadal znajduje się na blockchainie. Komunikacja klienta z blockchainem zazwyczaj odbywa się przez **portfel**.

Dobrym przykładem tego typu DApp jest **aplikacja do mintowania NFT**. Serwer umożliwia przesyłanie obrazów, ale mintowanie odbywa się przez klienta za pomocą portfela.

### DApps "pełnoskalowe"

Te DApps są budowane na blockchainie, ale również polegają na scentralizowanych API i serwerach backendowych. Mogą być **częściowo zdecentralizowane**, ponieważ klient może być w stanie wykonywać operacje na blockchainie za pomocą portfela. Jednak zazwyczaj **backend również będzie w stanie wykonywać operacje na blockchainie**.

Dobrym przykładem tego typu DApp jest most międzyłańcuchowy, gdzie komponent offchain jest potrzebny do **komunikacji z inteligentnymi kontraktami w różnych blockchainach** w celu przeprowadzenia transferu aktywów.

## Wrażliwości Web2

Wrażliwości Web2 nadal wpływają na tego rodzaju aplikacje, chociaż ich wpływ może się różnić:

- **Wrażliwości po stronie klienta** mają zwiększony wpływ, ponieważ w DApps Web3 klient zazwyczaj jest tym, który **wykonuje operacje na blockchainie** za pomocą portfela. Oznacza to, że ataki takie jak XSS, które udaje się wykonać kod JS po stronie klienta lub które manipulują treścią strony, mogą mieć większy wpływ, ponieważ mogą **interagować z portfelem** i przekonać użytkownika do wykonania niepożądanych operacji na blockchainie.
- Należy zauważyć, że zazwyczaj nawet w tego rodzaju aplikacjach klient może nadal przeglądać operacje przed ich podpisaniem za pomocą portfela. Jednak jeśli atakujący jest w stanie manipulować treścią strony, może przekonać użytkownika do podpisania transakcji, która wykona niepożądaną operację na blockchainie.
- **Wrażliwości po stronie serwera** nadal występują w DApps, które polegają na serwerze backendowym. Wpływ tych wrażliwości będzie zależał od architektury DApp. Mogą być jednak bardzo problematyczne, ponieważ atakujący może znaleźć w backendzie **klucze firmy** do uzyskania dostępu do funduszy inteligentnych kontraktów lub może przeprowadzić przejęcie konta, co może pozwolić mu na kradzież funduszy lub NFT od użytkowników.

Oczywiście, jeśli DApp nie używa backendu lub backend używany oferuje tylko dane publicznego łańcucha lub statyczne strony, powierzchnia ataku DApp jest zmniejszona.

## Powierzchnia ataku Web3

Nawet jeśli ogólnie DApp ma zmniejszoną powierzchnię ataku, ponieważ na blockchainie zawsze wykonywane są różne kontrole bezpieczeństwa, nadal istnieją pewne wektory ataku, które mogą być wykorzystywane przez atakującego.

Możliwe jest grupowanie wrażliwości DApps Web3 w następujące kategorie:

- **Niewłaściwie obsługiwane transakcje on-chain**: niepoprawnie sformatowane lub nieograniczone API transakcji, brak logiki oczekiwania na odpowiedź i potwierdzenie bloku, ujawnienie wrażliwych danych oraz niewłaściwe obsługiwanie nieudanych, odwróconych lub wewnętrznie typowanych transakcji, które pozwalają na wstrzykiwanie złośliwych danych.

- **Ataki z wykorzystaniem backendu napędzanego inteligentnymi kontraktami**: przechowywanie lub synchronizacja wrażliwych danych między kontraktami a bazami danych bez walidacji, niekontrolowane emisje zdarzeń lub adresy kontraktów oraz podatne na wykorzystanie wrażliwości kontraktów, które mogą zanieczyścić logikę backendu.

- **Błędne operacje na aktywach kryptograficznych**: niewłaściwe przetwarzanie różnych typów tokenów (native vs. ERC-20), ignorowanie precyzji dziesiętnej, nieudane transfery lub transakcje wewnętrzne oraz akceptowanie fałszywych, deflacyjnych, rebase'owych lub podatnych na poślizg tokenów bez walidacji, co umożliwia wstrzykiwanie ładunków za pomocą metadanych tokenów.

Kilka przykładów z [**tego posta**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications):

### Marnowanie funduszy: wymuszanie backendu do wykonywania transakcji

W scenariuszu **`Marnowane kryptowaluty w gazie za pomocą nieograniczonego API`**, atakujący może wymusić backend do wywołania funkcji inteligentnego kontraktu, które będą konsumować gaz. Atakujący, wysyłając tylko numer konta ETH i bez limitów, wymusi backend do wywołania inteligentnego kontraktu w celu jego zarejestrowania, co będzie konsumować gaz.

### DoS: Słaby czas obsługi transakcji

W scenariuszu **`Słaby czas obsługi transakcji prowadzi do DoS`**, wyjaśniono, że ponieważ backend będzie miał otwarte żądanie HTTP, aż transakcja zostanie wykonana, użytkownik może łatwo wysłać kilka żądań HTTP do backendu, co zużyje wszystkie zasoby backendu i doprowadzi do DoS.

### Desynchronizacja Backend<-->Blockchain - Warunek wyścigu

W scenariuszu **`Słaby czas obsługi transakcji prowadzi do warunku wyścigu`**, wyjaśniono, że w grze użytkownik mógł wysłać żądanie wypłaty do backendu, który wyśle użytkownikowi jego monety, ale podczas gdy transakcja była nadal przetwarzana, użytkownik mógł użyć tych monet do zakupu przedmiotów w grze, otrzymując je za darmo.

Innym przykładem może być możliwość użycia tych samych monet do zakupu różnych przedmiotów, ponieważ backend natychmiastowo przekazuje przedmiot użytkownikowi, nie czekając na potwierdzenie transakcji, a tym samym nie czekając na zmniejszenie salda użytkownika w blockchainie.

### Walidacja adresu inteligentnego kontraktu

W scenariuszu **`Backend mostu nie ma walidacji adresu inteligentnego kontraktu`** wyjaśniono, jak backend sprawdzał adres inteligentnego kontraktu, więc atakujący mógł wdrożyć fałszywy inteligentny kontrakt, umieścić na nim fundusze, wysłać transakcję do backendu, a backend pomyśli, że użytkownik wysłał fundusze do prawdziwego inteligentnego kontraktu i przyzna użytkownikowi tokeny.

### Niewłaściwe zarządzanie klasami aktywów

W scenariuszu **`Niewłaściwe zarządzanie klasami aktywów`**, wyjaśniono, że backend pomylił oszukańczego NFT w adresie z 1 MATIC, co pozwoliło atakującemu wysłać setki oszukańczych NFT do adresu i otrzymać 1 MATIC od platformy za każdy z nich.

## Odnośniki
- [https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications)

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