DApps - Decentralized Applications

Reading time: 5 minutes

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

What is a DApp?

A DApp is a decentralized application that runs on a peer-to-peer network, rather than being hosted on a centralized server. DApps are typically built on blockchain technology, which should allow for transparency, security, and immutability of data.

Web3 DApp Architecture

According to this post there are 3 different types of Web3 DApps architecture:

"API-less" DApps

These DApps are built on top of a blockchain and do not rely on any centralized APIs or backend. You could think that the blockchain is the actual backedn of the application. They are fully decentralized and can be accessed directly through the blockchain.

In order to interact with the blockchain the client will usually use a wallet. The wallet will sign the transactions and send them to the blockchain. The client might also use a node to read data from the blockchain.

"API-Enabled" DApps

These DApps are built on top of a blockchain but also rely on centralized APIs usually to gather information. They are mostly decentralized because even if they rely on a centralized API, the core functionality of the DApp is still on the blockchain. The communication of the client with the blockchain is usually done through a wallet.

A good example of this type of DApp is a NFT minting application. The server allows to uplaod the images but the minting us done by the client through a wallet.

"Full-Scale" DApps

These DApps are built on top of a blockchain but also rely on centralized APIs and backend servers. They could be partially decentralized as the client might be able to perform operations on the blockchain using a wallet. However, usually the backend will also be able to perform operations on the blockchain.

A good example for this type of DApp is a cross-chain bridge where an offchain component is needed to communicate with both smart contracts in different blockchains to perform the transfer of assets.

Web2 vulnerabilities

Web2 vulnerabilities still affect these kind of applications although thir impact might vary:

• Client side vulnerabilities have an increased impact as in the Web3 DApps the client is usually the one performing the operations on the blockchain through a wallet. This means that attacks like XSS that manage to execute JS code on the client side or that tampers with the content of the page can have a bigger impact as they can interact with the wallet and convince the user to perform undesired operations on the blockchain.
  • Note that usually even in these kind of applications the client can still review the operations before signing them with the wallet. However, if the attacker is able to tamper with the content of the page, it can convince the user to sign a transaction that will perform an undesired operation on the blockchain.
• Server side vulnerabilities are still present in the DApps that rely on a backend server. The impact of these vulnerabilities will depend on the architecture of the DApp. Hoewver, they could still be very problematic as an attacker might find in the backed keys of the company to access the fund of smart contracts, or could perform account takeover that might allow them steal funds or NFTs from the users.

Of course, if the DApp is not using a backend or the backend used only offers public chain data or static pages, the attack surface of the DApp is reduced.

Web3 attack surface

Even if in general a DApp has a reduces attack surface as several security checks are always done on the blockchain, there are still some attack vectors that can be exploited by an attacker.

It might be possible to group web3 DApps vulnerabilities in the following categories:

• Mishandled On-Chain Transactions: incorrectly formatted or unrestricted transaction APIs, lack of response-waiting and block-confirmation logic, exposure of sensitive data, and improper handling of failed, reverted, or internally-typed transactions that allow malicious calldata injections.

• Smart-Contract-Driven Backend Attacks: storing or syncing sensitive data between contracts and databases without validation, unchecked event emissions or contract addresses, and exploitable contract vulnerabilities that can poison backend logic.

• Flawed Crypto-Asset Operations: misprocessing different token types (native vs. ERC-20), ignoring decimal precision, failed transfers or internal transactions, and accepting fake, deflationary, rebase, or slippage-prone tokens without validation, enabling payload injections via token metadata.

Some examples from this post:

Wasting Funds: Forcing backend to perform transactions

In the scenario Wasted Crypto in Gas via Unrestricted API, the attacke can force the backend to call functions of a smart contract that will consume gas. The attacker, just sending an ETH account number and with no limits, will force backend to call the smart contrat to register it, which will consume gas.

DoS: Poor transaction handling time

In the scenario Poor Transaction Time Handling Leads to DoS, is explained that because the backend will the HTTP request open until a transaction is performed, a user can easly send several HTTP requests to the backend, which will consume all the resources of the backend and will lead to a DoS.

Backend<-->Blockchain desync - Race condition

In the scenario Poor Transaction Time Handling Leads to Race Condition, is explained that in a game it was possible for the user to send a withrowal request to the backend which will send to the user his coins but while the transaction was still being processed, the user was able to use those coins to purchase items in the game, getting them for free.

Another example could be to be able to use the same coins to purchase different items as the backend is inmediatelly giving the item to the user without waiting for the transaction to be confirmed and therefore waiting for the user balance in th blockchain to be reduced.

Smart contract address validation

In the scenario Bridge Backend Lacks Smart Contract Address Validation is explained how the backend was checking the address of the smart contract, so it was possible for an attacker to deploy a fake smart contract, put funds on it, send the transaction to the backend and the backend will think that the user sent funds to the real smart contract and will give the user the tokens.

Mishandling of Asset Classes

In the scenario Mishandling of Asset Classes, is explained that the backend confused a scam NFT in an address with 1 MATIC, therefore allowing attacker to send hundreds of scam NFTs to the address and getting 1 MATIC from the platform for each of them.

References

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

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