Shikata Ga Nai

Private? There is no such things.

情報漏洩脆弱性のテスト方法:見落とさない観察力とBurp Suiteの徹底活用

Hello there, ('ω')ノ

🔍 テストの心構え:視野を狭めないこと

情報漏洩は、別の脆弱性を探している過程で偶然見つかることが非常に多いです。常にレスポンスの細部に注意を払い、「これは他に使えそうだ」と思える情報を即座に拾えるようにしましょう。


🧪 情報漏洩を見つけるためのテスト手法

1. Fuzzing(ファズィング)

❓ 何をする?

  • 特定のパラメータに意図しないデータ型や特殊文字列を入力してアプリの挙動を観察。

✅ チェックポイント:

  • エラーメッセージにスタックトレースやSQL断片が出るか?
  • レスポンスの処理時間の変化(タイミングベースの情報漏洩)
  • 微妙なエラーの違いがリソースの存在を示唆していないか?

🛠 使用ツール:Burp Intruder

  • 事前定義された「fuzz文字列リスト」で高速に多種多様な入力を試す。
  • レスポンスの長さ、ステータスコード、タイミングなどを比較。
  • grep matchSELECT, error, invalid などのキーワードを検出。
  • grep extract:レスポンス内から特定部分を抽出・比較。

2. Burp Scanner(有料版)

🌐 できること

  • リアルタイムスキャンでブラウジング中に脆弱性を検出。
  • 自動クロール+診断でサイト全体をカバー。

✅ 発見される主な情報:

  • クレジットカード番号、APIキー、メールアドレス
  • ディレクトリリストやバックアップファイル
  • 開発環境の情報など

3. Burpの Engagement Tools(無料版でも使用可能)

💡 特に便利な3機能

ツール名 説明
Search HTTPデータ中からキーワードや正規表現で検索可能
Find comments HTMLコメント(開発者のメモ等)を一覧表示
Discover content サイトマップに出てこない隠しファイルや機能を検出可能

4. エラーを利用した情報抽出(Engineering Informative Responses)

📌 アプローチ:

  • 無効な操作を意図的に行い、アプリにエラーを出させる
  • エラーの内容に含まれる情報から、構造やデータ内容を逆引き

例:

  • 存在しないユーザーIDを指定 → 存在しない vs 存在するでメッセージが異なる
  • 無効なパラメータ送信 → スタックトレースやSQLエラーを誘発

5. Logger++(Burp拡張)

  • 全ツールのリクエスト/レスポンスを記録
  • フィルタ機能で興味深いレスポンス(例:error, debug, config)だけ表示

✅ まとめ

  • 情報漏洩のテストは「反射神経と気づきの勝負」。
  • すべてのレスポンスに「何か手がかりはないか?」という視点を持つ。
  • Burp SuiteのIntruder / Scanner / Engagement tools / Extensionsをフル活用する。

🔐 エラーメッセージの一言、HTMLコメントの一行、robots.txtの1文。これらの情報を「ただの文字列」で終わらせず、「どう使えるか?」を考えることが、プロのテスターへの第一歩です。

Best regards, (^^ゞ