From 2663d1c548cd3b1b530fdbd048abce769825ffdf Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Sun, 27 Apr 2025 16:45:57 +0000
Subject: [PATCH] Translated
 ['src/pentesting-web/dapps-DecentralizedApplications.md'] to

---
 .../dapps-DecentralizedApplications.md        | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 src/pentesting-web/dapps-DecentralizedApplications.md

diff --git a/src/pentesting-web/dapps-DecentralizedApplications.md b/src/pentesting-web/dapps-DecentralizedApplications.md
new file mode 100644
index 000000000..23baa5601
--- /dev/null
+++ b/src/pentesting-web/dapps-DecentralizedApplications.md
@@ -0,0 +1,80 @@
+# DApps - Decentralized Applications
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## What is a DApp?
+
+DAppは、中央集権的なサーバーではなく、ピアツーピアネットワーク上で動作する分散型アプリケーションです。DAppは通常、**ブロックチェーン技術**に基づいて構築されており、データの透明性、安全性、変更不可能性を可能にします。
+
+## Web3 DApp Architecture
+
+[**この投稿**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications)によると、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）の誤処理、小数点精度の無視、失敗した転送または内部トランザクション、検証なしに偽の、デフレ、リベース、またはスリッページに敏感なトークンを受け入れることにより、トークンメタデータを介してペイロード注入を可能にします。
+
+[**この投稿**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications)からのいくつかの例：
+
+### 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
+- [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}}