DVWA (Damn Vulnerable Web Application) 徹底解説ガイド

はじめに：DVWAとは？ 🤔

DVWA (Damn Vulnerable Web Application) は、その名の通り「意図的に脆弱性が組み込まれたWebアプリケーション」です。セキュリティ専門家、Web開発者、学生などが、Webアプリケーションのセキュリティについて学習したり、自身のスキルやツールを合法的な環境でテストしたりすることを主な目的として開発されました。

主な特徴は以下の通りです：

• 実践的な学習環境：SQLインジェクション、クロスサイトスクリプティング (XSS)、コマンドインジェクションなど、実際に発生しうる一般的なWeb脆弱性を安全に試すことができます。
• 難易度調整機能：Low (低)、Medium (中)、High (高)、Impossible (不可能) の4段階のセキュリティレベルが用意されており、学習者のスキルレベルに合わせて脆弱性への対策状況を変更できます。
• オープンソース：無料で利用でき、GitHubでソースコードが公開されています。コミュニティによるサポートも期待できます。
• 軽量：PHPとMySQL (またはMariaDB) で動作するため、比較的簡単にローカル環境や仮想環境にセットアップできます。

DVWAを利用することで、攻撃手法の仕組みや、脆弱性がどのように悪用されるのか、そしてそれらに対する効果的な防御策について、座学だけでなく実践を通して深く理解することができます。セキュリティ意識の向上や、セキュアなコーディングスキルの習得に非常に役立つツールです。

インストールとセットアップ 🛠️

DVWAを動作させるためには、いくつかの前提条件があります。その後、いくつかの方法でインストールできます。

前提条件

DVWAは主に以下のソフトウェア上で動作します：

• Webサーバー：ApacheまたはNginxなど
• スクリプト言語：PHP (特定のバージョンと拡張機能が必要な場合があります。例: mysqli, gd)
• データベース：MySQLまたはMariaDB

これらの環境を個別に用意することも可能ですが、XAMPP (Windows, macOS, Linux対応) や WAMP (Windows用)、MAMP (macOS用) といった、これらをパッケージ化したソフトウェアを利用すると簡単に環境を構築できます。

インストール方法

DVWAのインストールにはいくつかの一般的な方法があります。

# イメージのダウンロード
docker pull vulnerables/web-dvwa

# コンテナの起動 (ポート80をホストのポート80にマッピング)
# --rm オプションでコンテナ停止時に自動削除
docker run --rm -it -p 80:80 vulnerables/web-dvwa

# もしホストのポート80が使用中の場合は、別のポートにマッピングします (例: 8080番)
docker run --rm -it -p 8080:80 vulnerables/web-dvwa

初期設定

初めてDVWAにアクセスすると、多くの場合セットアップページが表示されます。

1. 通常、デフォルトのログイン認証情報は ユーザー名: admin、パスワード: password です。
2. ログイン後、「Setup / Reset DB」ページが表示されることがあります。ここで「Create / Reset Database」ボタンをクリックして、DVWAが使用するデータベースとテーブルを作成（または初期化）します。
3. データベースのセットアップが完了すると、再度ログインを求められるか、メインページにリダイレクトされます。

これでDVWAを使用する準備が整いました！ 🎉

基本的な使い方 🧭

DVWAのインターフェースはシンプルで直感的です。

• 左側のメニュー：学習したい脆弱性の種類を選択します。
• メインコンテンツエリア：選択した脆弱性の演習ページが表示されます。入力フォームやボタンなどが配置されています。
• DVWA Security：左側メニューの下部にあり、ここでセキュリティレベル (Low, Medium, High, Impossible) を変更できます。
• Setup / Reset DB：データベースを初期状態に戻したい場合に使用します。
• View Source / View Help：各脆弱性ページの右下にあり、「View Source」でそのページの脆弱なコード（PHP）を確認でき、「View Help」で簡単な解説やヒントを見ることができます。コードを読むことは、脆弱性の仕組みと対策を理解する上で非常に重要です。

セキュリティレベルの変更

DVWAの最大の特徴の一つが、セキュリティレベルを変更できることです。

脆弱性モジュールの解説 ⚔️

DVWAには様々な種類のWeb脆弱性を学ぶためのモジュールが含まれています。ここでは代表的なものをいくつか紹介します。

1. ブルートフォース (Brute Force)

概要: ログインフォームなどに対して、考えられるユーザー名やパスワードの組み合わせを総当たりで試行し、認証を突破しようとする攻撃です。

Lowレベルでの試行例: Lowレベルでは、ログイン試行回数に制限がなく、単純なユーザー名/パスワード (例: `admin/password`) が設定されています。HydraやBurp Suite Intruderのようなツールを使って、パスワードリストを用いた自動的な攻撃が容易に成功します。

# Hydraを使った例 (ユーザー名admin, パスワードリストを使用)
hydra -l admin -P /path/to/password-list.txt localhost http-post-form "/dvwa/vulnerabilities/brute/?username=^USER^&password=^PASS^&Login=Login:Login failed"

対策: アカウントロックアウト (一定回数失敗したらアカウントを一時停止)、CAPTCHAの導入、推測されにくい複雑なパスワードポリシーの強制、多要素認証 (MFA) など。

2. コマンドインジェクション (Command Injection)

概要: Webアプリケーションがユーザーからの入力を利用してOSコマンドを実行する機能を持つ場合、入力値に不正なOSコマンドを注入し、サーバー上で任意のコマンドを実行させる攻撃です。

Lowレベルでの試行例: Ping機能などでIPアドレスを入力するフォームがあるとします。Lowレベルでは入力値の検証が甘いため、IPアドレスの後ろにセミコロン (`;`) やパイプ (`|`, `||`, `&&`) などを付けて追加のコマンド (例: `ls -la`, `cat /etc/passwd`) を注入できます。

# 入力例: ターゲットIPアドレスの後に追加コマンドを注入
127.0.0.1; ls -la
127.0.0.1 | whoami

リスク: サーバーのファイルシステムへのアクセス、改ざん、情報漏洩、マルウェアの設置、他のシステムへの攻撃の踏み台化など、非常に深刻な被害につながる可能性があります。

対策: ユーザー入力をOSコマンドの引数として直接渡さない、エスケープ処理を適切に行う、外部コマンド実行を避けて内部APIや関数で代替する、入力値のホワイトリスト検証など。

3. CSRF (Cross-Site Request Forgery)

概要: ユーザーがログイン状態にあるWebアプリケーションに対し、ユーザー自身の意図しないリクエスト（例: パスワード変更、商品の購入など）を攻撃者の用意した罠サイトなどから強制的に送信させる攻撃です。

Lowレベルでの試行例: Lowレベルのパスワード変更フォームでは、リクエストが正規のものであるかを確認する仕組み（CSRFトークンなど）がありません。攻撃者は、被害者がログイン中に特定のURL（パスワード変更リクエストを含む）をクリックさせるだけで、パスワードを変更させることが可能です。

対策: CSRFトークン（リクエストごとに生成される推測困難な一時的なトークン）をフォームに埋め込み、サーバー側で検証する。SameSite Cookie属性を適切に設定する。重要な操作の前には再認証を要求するなど。

4. ファイルインクルード (File Inclusion)

概要: Webアプリケーションがユーザーからの入力に基づいてサーバー上のファイルを読み込む（インクルードする）機能を持つ場合、不正なパスを指定することで、本来アクセスされるべきでないファイル（設定ファイル、機密情報を含むファイルなど）を読み込ませたり、場合によっては外部のサーバーにある不正なスクリプト（RFI: Remote File Inclusion）を実行させたりする攻撃です。

Lowレベルでの試行例: `page` パラメータで表示するファイル名を指定するような機能で、`../../../../etc/passwd` のようなディレクトリトラバーサルを利用してシステムファイルを指定すると、その内容が表示されてしまうことがあります (LFI: Local File Inclusion)。

対策: ユーザー入力に基づいてファイルパスを組み立てない、読み込むファイルをホワイトリストで厳格に管理する、PHPの設定で `allow_url_include` を無効化してRFIを防ぐ、適切なファイルアクセス権限を設定するなど。

5. ファイルアップロード (File Upload)

概要: ファイルアップロード機能を持つWebアプリケーションにおいて、ファイルの種類や内容に関する検証が不十分な場合、攻撃者が実行可能なスクリプトファイル（例: PHPのWebシェル）などをアップロードし、サーバー上で実行させる攻撃です。

Lowレベルでの試行例: Lowレベルでは、アップロードされるファイルの拡張子や内容のチェックが行われないか、非常に甘いです。単純なPHPのWebシェル (``) を含むファイルをアップロードし、そのファイルにアクセスして任意のOSコマンドを実行できます。

対策: ファイル拡張子のホワイトリスト検証（ブラックリストは回避されやすい）、ファイルの内容（MIMEタイプ、マジックナンバー）の検証、アップロードされたファイルの名前を推測困難なものに変更する、アップロードされたファイルをWebサーバーのドキュメントルート外の安全な場所に保存し、直接アクセスできないようにする、ファイルに対する実行権限を与えないなど。

6. SQLインジェクション (SQL Injection)

概要: Webアプリケーションがユーザーからの入力を利用してデータベースへの問い合わせ（SQLクエリ）を組み立てる際に、入力値に不正なSQLコードを注入することで、データベースを不正に操作する攻撃です。情報の窃取、改ざん、削除、認証回避などが可能になります。

Lowレベルでの試行例: ユーザーIDを入力してユーザー情報を検索する機能で、入力値が直接SQLクエリに埋め込まれる場合、`1′ OR ‘1’=’1` のような入力を行うことで、WHERE句の条件を常に真にし、データベース内の全ユーザー情報を取得したり、認証を回避したりできます。

-- 元のクエリが SELECT * FROM users WHERE user_id = '$id'; の場合
-- $id に "1' OR '1'='1" を入力すると...
SELECT * FROM users WHERE user_id = '1' OR '1'='1'; -- 条件が常に真になる

ツール (例: sqlmap) を使うことで、より複雑な攻撃 (Blind SQL Injectionなど) も自動化できます。

対策: プリペアードステートメント (Prepared Statements) またはパラメータ化クエリ (Parameterized Queries) を使用する。これが最も効果的で推奨される対策です。ユーザー入力をエスケープする処理も補助的に有効ですが、完全ではありません。入力値のバリデーション（型、長さ、形式など）を行う。データベースのエラーメッセージをユーザーに詳細に表示しない。

7. SQLインジェクション (Blind)

概要: 通常のSQLインジェクションのようにデータベースからの応答内容が直接表示されない場合に用いられる手法です。クエリの結果が真か偽かによる応答の違い (Boolean-based Blind) や、クエリの実行にかかる時間の違い (Time-based Blind) を利用して、少しずつ情報を窃取していきます。

Lowレベルでの試行例: 時間ベースの場合、`1′ AND SLEEP(5)–` のような入力を試行し、応答に5秒余計に時間がかかれば、インジェクションが可能であると判断できます。その後、条件分岐とSLEEP関数を組み合わせてデータベースの情報を1文字ずつ特定していきます。

対策: 通常のSQLインジェクション対策と同様、プリペアードステートメントの使用が最も重要です。

8. クロスサイトスクリプティング (XSS – Reflected)

概要: 攻撃者が用意した不正なスクリプトを含むURLを被害者にクリックさせるなどして、被害者のブラウザ上でそのスクリプトを実行させる攻撃です。スクリプトはサーバーには保存されず、リクエストに含まれたスクリプトがそのままレスポンスに「反映 (Reflected)」されて実行されます。

Lowレベルでの試行例: 検索フォームやパラメータを含むURLなどで、入力値がそのままHTMLに出力される場合、`` のようなスクリプトを入力（またはURLパラメータとして付与）すると、それがそのままHTMLに含まれ、ブラウザで実行されてアラートが表示されます。

<!-- 入力フォームに以下を入力 -->
<script>alert(document.cookie);</script>

リスク: 被害者のセッションCookieの窃取（なりすまし）、個人情報の詐取、Webページの改ざん（に見せかける）、マルウェアサイトへの誘導など。

対策: 出力時のエスケープ処理（HTMLエンティティ化など）が最も重要です。入力値のバリデーションも行います。Content Security Policy (CSP) を導入して、信頼できるスクリプトソースを制限することも有効です。

9. クロスサイトスクリプティング (XSS – Stored)

概要: 攻撃者が不正なスクリプトをWebアプリケーションのデータベースなどに「保存 (Stored)」させ、そのデータを含むページを他のユーザーが閲覧した際に、被害者のブラウザ上でスクリプトを実行させる攻撃です。掲示板、コメント欄、ユーザープロフィールなどがターゲットになりやすいです。

Lowレベルでの試行例: ゲストブックやコメント欄に `` を含むメッセージを投稿します。他のユーザーがそのページを開くと、保存されたスクリプトが実行されます。

リスク: Reflected XSSと同様のリスクに加え、一度スクリプトが保存されると、ページを訪れる不特定多数のユーザーが被害に遭う可能性があり、影響範囲が広がりやすいです。

対策: Reflected XSSと同様、出力時のエスケープ処理、入力値のバリデーション、CSPの導入が重要です。特に、ユーザーが入力した内容をデータベースに保存する前と、データベースから読み出して表示する際の両方で適切な処理が必要です。

10. クロスサイトスクリプティング (XSS – DOM-based)

概要: サーバー側の処理ではなく、ブラウザ上のJavaScriptがDOM (Document Object Model) を操作する際に、ユーザー入力などの信頼できないデータを適切に処理しないことが原因で発生するXSSです。URLのフラグメント (`#`以降の部分) など、サーバーに送信されないデータが原因となることもあります。

Lowレベルでの試行例: URLの `#` 以降の値を取得して、それを `document.write()` や `innerHTML` などでDOMに書き込むようなJavaScriptコードがある場合、`http://example.com/page#` のようなURLにアクセスさせることで、スクリプトを実行させることが可能です。

対策: 信頼できないデータをDOMに書き込む際に、適切なサニタイズ処理（JavaScript側でのエスケープなど）を行う。`innerHTML` の代わりに `textContent` を使うなど、安全なDOM操作APIを選択する。信頼できないデータを `eval()` や `setTimeout()` などで直接実行しない。

これらはDVWAに含まれる脆弱性の一部です。他にもWeak Session IDsなど、様々なモジュールが用意されています。各モジュールをLowレベルから順に試していき、レベルを上げることで対策がどのように変化するかを確認し、「View Source」で実際のコードを読むことで、理解を深めていきましょう。

⚠️ 注意事項と倫理的利用

DVWAを使用する際は、これらの点を十分に理解し、倫理観を持って安全に利用することが求められます。