DApps - Decentralized Applications

Reading time: 9 minutes

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

What is a DApp?

DAppは、中央集権的なサーバーではなく、ピアツーピアネットワーク上で動作する分散型アプリケーションです。DAppは通常、ブロックチェーン技術に基づいて構築されており、データの透明性、安全性、変更不可能性を可能にします。

Web3 DApp Architecture

この投稿によると、Web3 DAppアーキテクチャには3つの異なるタイプがあります。

"API-less" DApps

これらのDAppはブロックチェーンの上に構築されており、中央集権的なAPIやバックエンドに依存しません。ブロックチェーンがアプリケーションの実際のバックエンドであると考えることができます。これらは完全に分散型であり、ブロックチェーンを通じて直接アクセスできます。

ブロックチェーンと対話するために、クライアントは通常ウォレットを使用します。ウォレットはトランザクションに署名し、それをブロックチェーンに送信します。クライアントはまた、ブロックチェーンからデータを読み取るためにノードを使用することもあります。

"API-Enabled" DApps

これらのDAppはブロックチェーンの上に構築されていますが、通常は情報を収集するために中央集権的なAPIに依存しています。これらは主に分散型であり、中央集権的なAPIに依存していても、DAppのコア機能は依然としてブロックチェーン上にあります。クライアントとブロックチェーンの通信は通常ウォレットを通じて行われます。

このタイプのDAppの良い例はNFTミンティングアプリケーションです。サーバーは画像のアップロードを許可しますが、ミンティングはクライアントがウォレットを通じて行います。

"Full-Scale" DApps

これらのDAppはブロックチェーンの上に構築されていますが、中央集権的なAPIやバックエンドサーバーにも依存しています。クライアントはウォレットを使用してブロックチェーン上で操作を行うことができるため、部分的に分散型である可能性があります。しかし、通常はバックエンドもブロックチェーン上で操作を行うことができます。

このタイプのDAppの良い例は、オフチェーンコンポーネントが必要なクロスチェーンブリッジで、異なるブロックチェーンのスマートコントラクトと通信して資産の移転を行います。

Web2 vulnerabilities

Web2の脆弱性は、これらのアプリケーションにも影響を与えますが、その影響は異なる場合があります。

  • クライアント側の脆弱性は、Web3 DAppではクライアントが通常ウォレットを通じてブロックチェーン上で操作を行うため、影響が増大します。これは、クライアント側でJSコードを実行したり、ページの内容を改ざんする攻撃（XSSなど）が、ウォレットと相互作用し、ユーザーに望ましくない操作をブロックチェーン上で実行させる可能性があるためです。
  • 通常、これらのアプリケーションでもクライアントはウォレットで署名する前に操作を確認できます。しかし、攻撃者がページの内容を改ざんできる場合、ユーザーに望ましくない操作を行うトランザクションに署名させることができます。
  • サーバー側の脆弱性は、バックエンドサーバーに依存するDAppにも存在します。これらの脆弱性の影響はDAppのアーキテクチャによって異なります。しかし、攻撃者がバックエンドで会社の鍵を見つけてスマートコントラクトの資金にアクセスしたり、アカウントの乗っ取りを行い、ユーザーから資金やNFTを盗む可能性があるため、非常に問題になる可能性があります。

もちろん、DAppがバックエンドを使用していない場合や、バックエンドが公開チェーンデータや静的ページのみを提供している場合、DAppの攻撃面は減少します。

Web3 attack surface

一般的にDAppは、ブロックチェーン上で常にいくつかのセキュリティチェックが行われるため、攻撃面が減少していますが、攻撃者によって悪用される可能性のある攻撃ベクトルは依然として存在します。

Web3 DAppの脆弱性を以下のカテゴリに分類することができるかもしれません。

  • 不適切に処理されたオンチェーントランザクション: 不正にフォーマットされたまたは制限のないトランザクションAPI、応答待機およびブロック確認ロジックの欠如、機密データの露出、悪意のあるコールデータ注入を許可する失敗、取り消し、または内部型トランザクションの不適切な処理。

  • スマートコントラクト駆動のバックエンド攻撃: 検証なしに契約とデータベース間で機密データを保存または同期すること、チェックされていないイベントの発生や契約アドレス、バックエンドロジックを汚染する可能性のある契約の脆弱性。

  • 欠陥のある暗号資産操作: 異なるトークンタイプ（ネイティブvs. ERC-20）の誤処理、小数点精度の無視、失敗した転送または内部トランザクション、検証なしに偽の、デフレ、リベース、またはスリッページに敏感なトークンを受け入れることにより、トークンメタデータを介してペイロード注入を可能にします。

この投稿からのいくつかの例：

Wasting Funds: Forcing backend to perform transactions

シナリオ**Wasted Crypto in Gas via Unrestricted API**では、攻撃者はバックエンドにガスを消費するスマートコントラクトの関数を呼び出させることができます。攻撃者はETHアカウント番号を送信するだけで制限なしに、バックエンドにスマートコントラクトを登録させ、ガスを消費させます。

DoS: Poor transaction handling time

シナリオ**Poor Transaction Time Handling Leads to DoS**では、バックエンドがトランザクションが実行されるまでHTTPリクエストを開いたままにするため、ユーザーがバックエンドに対して複数のHTTPリクエストを簡単に送信でき、バックエンドのリソースをすべて消費し、DoSにつながることが説明されています。

Backend<-->Blockchain desync - Race condition

シナリオ**Poor Transaction Time Handling Leads to Race Condition**では、ゲーム内でユーザーがバックエンドに引き出しリクエストを送信し、トランザクションが処理されている間にそのコインを使用してゲーム内のアイテムを購入できることが説明されています。これにより、無料でアイテムを取得できます。

別の例として、バックエンドがトランザクションの確認を待たずにユーザーにアイテムを即座に渡すため、同じコインを使用して異なるアイテムを購入できる可能性があります。

Smart contract address validation

シナリオ**Bridge Backend Lacks Smart Contract Address Validation**では、バックエンドがスマートコントラクトのアドレスをチェックしていたため、攻撃者が偽のスマートコントラクトをデプロイし、資金をその上に置き、トランザクションをバックエンドに送信すると、バックエンドはユーザーが本物のスマートコントラクトに資金を送信したと考え、ユーザーにトークンを与えることができることが説明されています。

Mishandling of Asset Classes

シナリオ**Mishandling of Asset Classes**では、バックエンドがアドレス内の詐欺NFTを1 MATICと混同し、攻撃者がそのアドレスに数百の詐欺NFTを送信し、プラットフォームからそれぞれ1 MATICを取得できることが説明されています。

References

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