DApps - 분산 애플리케이션

DApp이란 무엇인가?

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

Web3 DApp 아키텍처

이 게시물에 따르면 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) 잘못 처리, 소수점 정밀도 무시, 실패한 전송 또는 내부 거래, 검증 없이 가짜, 디플레이션, 리베이스 또는 슬리피지에 취약한 토큰 수용, 토큰 메타데이터를 통한 페이로드 주입 가능.

이 게시물에서 몇 가지 예시:

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

제한 없는 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