脆弱性診断レポートってどう書けば良い？ Part 1 【連日投稿day26】

連日投稿26日目。脆弱性診断レポートを作ってみます。

今回の目的

セキュリティエンジニアとして、脆弱性診断を実施したら、結果をレポートとして出さないといけないという事で、手探りで作ってみた。
一旦今日は自分の頭で思いつく限りのことをやってみて、明日以下書籍を読みながらフィックスする事で、ベストプラクティスを確認しようと思います。
https://www.shoeisha.co.jp/book/detail/9784798159164

このチャレンジについて
目的: セキュリティエンジニアとしての技術力向上
手段: 手動・自作ツールでの脆弱性診断を通じて学習
実施する事: 自動化,監視,ツール開発基礎学習など

目次

• 実行結果
• 実行環境
• まとめ

実行結果

今回は以下のフォーマットで作成してみた。
前提として、

• DVWAを自社のWEBシステムと仮定。
• 自社の経営層に、WEBシステムの脆弱性について診断結果を報告している というシチュエーションをイメージ。
• 診断内容はday23~25までの内容を実施した体とする。
  以上の仮定で作成するならこんな感じかな～といった次第です。

# 弊社ウェブサイト 脆弱性診断報告書

## 1. 診断概要
本報告書は、弊社ウェブサイトに対して実施されたセキュリティ評価の結果を詳述するものです。評価の結果、SQLインジェクション、反射型クロスサイトスクリプティング（XSS）、クロスサイトリクエストフォージェリ（CSRF）など、複数の重大な脆弱性が特定されました。これらの脆弱性は、データ盗難やユーザーセッションのハイジャック、不正なアカウント操作など、アプリケーションを重大なリスクに晒します。早急な修正を推奨します。

### 1.1. 診断対象
*   **対象:** 弊社ウェブサイト
*   **URL:** `http://<IP>/`

### 1.2. 診断期間
*   2025年9月15日 - 2025年9月17日

### 1.3. 診断環境
*   **診断者:** inugasuki44
*   **診断元:** ローカルネットワーク上のPC (Windows 10)
*   **診断ツール:** Python 3.x, `requests`, `beautifulsoup4`

## 2. 診断結果

### 2.1. 総合結果
今回の診断では、貴社ウェブサイトにおいて**3件**の重大な脆弱性が発見されました。これらの脆弱性を放置すると、データベース内の情報漏洩、顧客のセッション乗っ取り、意図しないアカウント情報の改ざんといった深刻なセキュリティインシデントに繋がる可能性があります。早急な対策を強く推奨します。

発見された脆弱性は以下の通りです。

*   **【脆弱性No.1】 SQLインジェクション (深刻度: 高)**
*   **【脆弱性No.2】 反射型クロスサイト・スクリプティング (XSS) (深刻度: 中)**
*   **【脆弱性No.3】 クロスサイトリクエストフォージェリ (CSRF) (深刻度: 高)**

### 2.2. 個別の脆弱性の詳細

---

#### 【No.1】 SQLインジェクション

*   **発見場所:**
    *   `/vulnerabilities/sqli/` ページの `id` パラメータ
*   **脆弱性の内容:**
    ユーザーIDを指定する入力欄において、入力値が安全な形に処理されないままデータベースへの命令文として直接利用されていました。これにより、攻撃者はデータベースを不正に操作し、登録されている全ての顧客情報を盗み見たり、改ざんしたりすることが可能です。
*   **再現手順:**
    ユーザーIDの入力欄に `'` のような特殊な文字を含む値を入力すると、サーバーがエラーを返すことから本脆弱性が存在することを確認しました。
*   **危険性:**
    データベースに格納されている個人情報や認証情報など、全ての情報が窃取、改ざん、削除される可能性があります。
*   **推奨される対策:**
    ユーザーからの入力をデータベースへの命令文に組み込む際は、必ず**プリペアドステートメント**と呼ばれる安全な仕組みを使用してください。これにより、入力値は命令の一部としてではなく、単なるデータとして扱われるようになります。

---

#### 【No.2】 反射型クロスサイト・スクリプティング (XSS)

*   **発見場所:**
    *   `/vulnerabilities/xss_r/` ページの `name` パラメータ
*   **脆弱性の内容:**
    名前を入力する欄において、入力された値が安全な形に処理されないまま、ウェブページ上にそのまま表示されていました。これにより、攻撃者は悪意のあるプログラム（スクリプト）をページに埋め込み、サイトを閲覧した他のユーザーのブラウザ上で実行させることが可能です。
*   **再現手順:**
    名前の入力欄に `<div id='xss_test_marker'></div>` のようなHTMLタグを注入すると、それがウェブページの構造の一部として組み込まれることを確認しました。
*   **危険性:**
    攻撃者は、偽の入力フォームを表示してユーザーの個人情報を盗んだり（フィッシング）、ユーザーのセッション情報を盗んでアカウントを乗っ取ったり（セッションハイジャック）することが可能になります。
*   **推奨される対策:**
    ユーザーからの入力をウェブページに表示する際は、必ずHTMLタグとして解釈されないよう、**適切なエスケープ処理**（例: `<` を `&lt;` に変換）を実装してください。

---

#### 【No.3】 クロスサイトリクエストフォージェリ (CSRF)

*   **発見場所:**
    *   `/vulnerabilities/csrf/` ページのパスワード変更機能
*   **脆弱性の内容:**
    パスワード変更機能において、そのリクエストが正規のユーザーによって意図されたものであるかを検証する仕組み（CSRF対策トークン）がありませんでした。これにより、攻撃者は、ログイン中のユーザーに悪意のあるリンクをクリックさせるだけで、意図せずパスワードを変更させることが可能です。
*   **再現手順:**
    攻撃者が用意した罠のリンクをログイン中のユーザーがクリックすると、パスワードが強制的に変更されてしまうことを確認しました。
*   **危険性:**
    ユーザーのアカウントが乗っ取られ、不正利用される可能性があります。
*   **推奨される対策:**
    パスワードの変更など、重要な操作を行う全てのフォームに**CSRF対策トークン**を導入してください。これは、正規のページから送信されたリクエストであることを証明する「合言葉」のようなもので、第三者による不正なリクエストを防ぎます。

実行環境

• テスト対象: DVWA (Docker上で稼働)
• セキュリティレベル: Low

まとめ

個別の脆弱性についてひとまず羅列してみたが、結局これらの優先度比較や、予想される被害の程度などを盛り込めていないので、「経営層に報告するレポート」という前提ではちょっと弱かったかな と考えている。
明日別途書籍を読みながら、修正ポイントを模索してみたい。