セキュリティ

脆弱性診断の結果をどう捌くか — 検出結果のトリアージと是正の優先順位

· by IT.Skill

脆弱性診断を回すと、数十から数百の指摘が出ます。
はじめて見ると途方に暮れますが、全部を同じ重さで扱わないのが実務です。

まず「本当に危ないもの」を分ける

ツールの Risk 表示をそのまま信じず、次の観点で並べ替えます。

  1. 認証を突破されるか（認証・認可の不備）
  2. 他人のデータが見えるか（IDOR、権限チェック漏れ）
  3. サーバー側で任意の処理が動くか（インジェクション系）
  4. 利用者のブラウザで任意の処理が動くか（XSS）
  5. それ以外（ヘッダー不足、情報露出など）

1〜3 は最優先で止めます。4 は影響範囲を見て判断、5 は計画的に直します。

誤検知を見分ける

自動診断は誤検知を必ず含みます。再現手順を自分で踏むまで報告しません。

1. 指摘されたリクエストを手で再送する
2. 実際に想定外の応答が返るかを確認する
3. 返らない場合、なぜツールがそう判断したかを推測する
   （多くはエラーページの文言や応答時間の差）

この確認を飛ばすと、直す必要のない箇所を直すことになり、
本当に危ない指摘に使う時間が減ります。

認可まわりは自動診断では見つからない

ツールが最も苦手なのがここです。ログイン状態を持たせても、
「Aさんのトークンで Bさんのデータが取れる」ことは自動では判定できません。

手で確認します。

・ユーザーAでログインし、自分のリソースIDを控える
・ユーザーBでログインし、AのIDを指定して叩く
・404 ではなく 200 が返ったら、そこが穴

実務でいちばん重い指摘は、たいていこの手動確認から出てきます。

トークンの失効を確認する

ログアウトしたのにトークンが使い続けられる、という状態は珍しくありません。

1. ログインしてトークンを取得
2. ログアウト
3. 控えておいたトークンで API を叩く
4. 401 が返れば正しい。200 なら失効処理が効いていない

多要素認証も同様で、設定した後に迂回できる経路が残っていないかを確認します。
「二要素を有効にする前に取得したセッションが生き続ける」といった穴がよくあります。

依存パッケージ

アプリのコードを直しても、ライブラリが古ければそこが穴になります。

pip list --outdated
pip-audit          # 既知の脆弱性を照合
npm audit

バージョンを上げられない事情がある場合は、上げられない理由と
代替の緩和策（WAF ルール、機能の無効化）をセットで記録に残します。

是正した後に必ずもう一度回す

直したつもりで直っていないことがあります。
同じ診断をもう一度流し、指摘が消えたことを確認して初めて完了とします。

再発防止として、認可まわりのテストは自動テストに落としておきます。

def test_other_users_resource_is_not_accessible(self):
    self.client.force_login(self.user_b)
    res = self.client.get(f"/api/orders/{self.order_of_user_a.id}/")
    self.assertEqual(res.status_code, 404)

まとめ

  • Risk 表示を鵜呑みにせず、認証 → 認可 → インジェクション の順で並べ替える
  • 再現できたものだけを報告する（誤検知に時間を奪われない）
  • 認可とトークン失効は手で確認する。自動診断では出ない
  • 是正後にもう一度診断を回し、テストに落として再発を防ぐ

関連記事