# DApps - 분산 애플리케이션

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

## DApp이란 무엇인가?

DApp은 중앙 서버에 호스팅되지 않고 피어 투 피어 네트워크에서 실행되는 분산 애플리케이션입니다. DApp은 일반적으로 **블록체인 기술**을 기반으로 구축되어 데이터의 투명성, 보안 및 불변성을 허용해야 합니다.

## Web3 DApp 아키텍처

[**이 게시물**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications)에 따르면 Web3 DApp 아키텍처에는 3가지 유형이 있습니다:

### "API 없는" DApps

이 DApp은 블록체인 위에 구축되며 중앙 집중식 API나 백엔드에 의존하지 않습니다. 블록체인이 애플리케이션의 실제 백엔드라고 생각할 수 있습니다. 이들은 **완전히 분산화**되어 있으며 블록체인을 통해 직접 접근할 수 있습니다.

블록체인과 상호작용하기 위해 클라이언트는 일반적으로 **지갑**을 사용합니다. 지갑은 거래에 서명하고 이를 블록체인에 전송합니다. 클라이언트는 블록체인에서 데이터를 읽기 위해 **노드**를 사용할 수도 있습니다.

### "API 사용 가능" DApps

이 DApp은 블록체인 위에 구축되지만 일반적으로 정보를 수집하기 위해 중앙 집중식 API에 의존합니다. 이들은 **대부분 분산화**되어 있으며, 중앙 집중식 API에 의존하더라도 DApp의 핵심 기능은 여전히 블록체인에 있습니다. 클라이언트와 블록체인 간의 통신은 일반적으로 **지갑**을 통해 이루어집니다.

이 유형의 DApp의 좋은 예는 **NFT 민팅 애플리케이션**입니다. 서버는 이미지를 업로드할 수 있도록 하지만 민팅은 클라이언트가 지갑을 통해 수행합니다.

### "풀 스케일" DApps

이 DApp은 블록체인 위에 구축되지만 중앙 집중식 API와 백엔드 서버에 의존합니다. 이들은 **부분적으로 분산화**될 수 있으며, 클라이언트는 지갑을 사용하여 블록체인에서 작업을 수행할 수 있습니다. 그러나 일반적으로 **백엔드도 블록체인에서 작업을 수행할 수 있습니다**.

이 유형의 DApp의 좋은 예는 자산 전송을 수행하기 위해 **다양한 블록체인에서 스마트 계약과 통신**해야 하는 크로스 체인 브리지입니다.

## Web2 취약점

Web2 취약점은 이러한 종류의 애플리케이션에도 여전히 영향을 미치지만 그 영향은 다를 수 있습니다:

- **클라이언트 측 취약점**은 Web3 DApp에서 클라이언트가 일반적으로 **지갑을 통해 블록체인에서 작업을 수행하는** 경우 영향이 증가합니다. 이는 XSS와 같은 공격이 클라이언트 측에서 JS 코드를 실행하거나 페이지의 내용을 변조할 수 있어, **지갑과 상호작용**하고 사용자가 블록체인에서 원하지 않는 작업을 수행하도록 설득할 수 있는 더 큰 영향을 미칠 수 있음을 의미합니다.
- 일반적으로 이러한 종류의 애플리케이션에서도 클라이언트는 지갑으로 서명하기 전에 작업을 검토할 수 있습니다. 그러나 공격자가 페이지의 내용을 변조할 수 있다면 사용자가 블록체인에서 원하지 않는 작업을 수행하는 거래에 서명하도록 설득할 수 있습니다.
- **서버 측 취약점**은 여전히 백엔드 서버에 의존하는 DApp에서 존재합니다. 이러한 취약점의 영향은 DApp의 아키텍처에 따라 달라집니다. 그러나 공격자가 백엔드에서 **회사의 키**를 찾아 스마트 계약의 자금을 접근하거나 계정 탈취를 수행하여 사용자로부터 자금이나 NFT를 훔칠 수 있는 경우 매우 문제가 될 수 있습니다.

물론 DApp이 백엔드를 사용하지 않거나 백엔드가 공용 체인 데이터나 정적 페이지만 제공하는 경우 DApp의 공격 표면은 줄어듭니다.

## Web3 공격 표면

일반적으로 DApp은 블록체인에서 항상 여러 보안 검사가 수행되기 때문에 공격 표면이 줄어들지만, 여전히 공격자가 악용할 수 있는 몇 가지 공격 벡터가 있습니다.

Web3 DApp의 취약점을 다음과 같은 범주로 그룹화할 수 있습니다:

- **온체인 거래 처리 오류**: 잘못된 형식 또는 제한 없는 거래 API, 응답 대기 및 블록 확인 로직 부족, 민감한 데이터 노출, 실패, 되돌림 또는 내부 유형 거래의 부적절한 처리로 인해 악의적인 calldata 주입이 가능해집니다.

- **스마트 계약 기반 백엔드 공격**: 검증 없이 계약과 데이터베이스 간에 민감한 데이터를 저장하거나 동기화, 체크되지 않은 이벤트 방출 또는 계약 주소, 백엔드 로직을 오염시킬 수 있는 악용 가능한 계약 취약점.

- **결함 있는 암호 자산 운영**: 다양한 토큰 유형(네이티브 vs. ERC-20) 잘못 처리, 소수점 정밀도 무시, 실패한 전송 또는 내부 거래, 검증 없이 가짜, 디플레이션, 리베이스 또는 슬리피지에 취약한 토큰 수용, 토큰 메타데이터를 통한 페이로드 주입 가능.

[**이 게시물**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications)에서 몇 가지 예시:

### 자금 낭비: 백엔드에 거래 수행 강제

**`제한 없는 API를 통한 가스 낭비`** 시나리오에서 공격자는 백엔드가 가스를 소모하는 스마트 계약의 함수를 호출하도록 강제할 수 있습니다. 공격자는 ETH 계좌 번호를 보내고 제한 없이 백엔드가 스마트 계약을 등록하도록 강제하여 가스를 소모하게 합니다.

### DoS: 불량 거래 처리 시간

**`불량 거래 시간 처리가 DoS로 이어짐`** 시나리오에서는 백엔드가 거래가 수행될 때까지 HTTP 요청을 열어두기 때문에 사용자가 백엔드에 여러 HTTP 요청을 쉽게 보내 백엔드의 모든 자원을 소모하게 되어 DoS로 이어질 수 있다고 설명합니다.

### 백엔드<-->블록체인 비동기 - 경쟁 조건

**`불량 거래 시간 처리가 경쟁 조건으로 이어짐`** 시나리오에서는 게임에서 사용자가 백엔드에 출금 요청을 보내고 거래가 처리되는 동안 그 코인을 사용하여 게임에서 아이템을 구매할 수 있었던 경우를 설명합니다. 사용자는 무료로 아이템을 얻을 수 있었습니다.

또 다른 예시는 백엔드가 거래가 확인될 때까지 기다리지 않고 즉시 아이템을 사용자에게 제공하여 동일한 코인을 사용하여 다른 아이템을 구매할 수 있는 경우입니다.

### 스마트 계약 주소 검증

**`브리지 백엔드가 스마트 계약 주소 검증 부족`** 시나리오에서는 백엔드가 스마트 계약의 주소를 확인하고 있었기 때문에 공격자가 가짜 스마트 계약을 배포하고 자금을 넣은 후 거래를 백엔드에 보내면 백엔드가 사용자가 실제 스마트 계약에 자금을 보냈다고 생각하고 사용자에게 토큰을 제공하게 됩니다.

### 자산 클래스 처리 오류

**`자산 클래스 처리 오류`** 시나리오에서는 백엔드가 주소에 있는 사기 NFT를 1 MATIC으로 혼동하여 공격자가 수백 개의 사기 NFT를 해당 주소로 보내고 플랫폼에서 각각 1 MATIC을 받도록 허용했다고 설명합니다.

## 참고 문헌
- [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}}