AlienGate で認証付きスキャンを実行する方法

• 対象読者: ログイン後のページも Web Application Scan でテストしたいセキュリティエンジニアおよびアプリケーション担当者
• 適用範囲: app.aliengate.io — Infrastructure Security → Vulnerability Scanner → Scanner Console → 認証付きスキャン (Authenticated scan)
• 所要時間: 設定と確認に約 5 分。スキャン自体の所要時間は通常の Web Application Scan と同じです
• 前提記事: 記事 01 — 脆弱性診断の実行方法

このガイドで実現できること

このガイドを終えると、次のことができるようになります。

• クロールの前にアプリケーションへログインする Web Application Scan。ログイン後のページもテスト対象になります。
• AlienGate がサポートする 3 つの方式、ログインフォーム (Login form)、Cookie (Cookies)、ヘッダー (Headers) の中から、お使いのアプリケーションに適した認証方式の選択。
• スキャン時間を費やす前にログインの成否を確かめられる 認証を確認 (Check authentication) の結果。
• 完了したスキャンから、認証付きの部分が実際に実行されたかどうかを判断する方法。

開始前の注意: 必ず専用のテストアカウントを使用してください。実在するユーザーのアカウントは使用しないでください。認証情報はこのスキャンのために一度だけスキャンエンジンへ渡され、スキャンがキューで待機している間は暗号化された状態でのみ保存され、その後は二度と表示されません。ただし、認証付きのディープスキャンでは、そのユーザーとしてフォームの送信やリンクの巡回を行い、実際のリクエストを数千件送信します。可能であればまずステージング環境で実行し、担当チームにも事前に連絡してください。

なぜ認証付きでスキャンするのか

認証なしのスキャンで見えるのは、訪問者に見えるもの、つまりログインページやマーケティングページなど、公開されている部分だけです。実際のアプリケーションの大部分、たとえばアカウント領域、管理画面、フロントエンドが呼び出す API、ファイルアップロード、検索機能は、セッションが確立されて初めて存在します。スキャナーがセッションを取得できなければ、これらは一切テストされず、レポートには到達していないコードについて「検出事項なし」と記載されることになります。

もう 1 つ理由があります。認証付きスキャンは悪意を持ったログイン済みユーザーとして動作します。これは匿名ユーザーよりも攻撃対象領域が大きく、性質も異なります。インジェクションの対象となるフォーム、改ざんできるパラメーター、ID で参照できるオブジェクトがいずれも増えるためです。OWASP Top 10 の中で最も一般的な脆弱性クラスであるアクセス制御の不備は、セッションなしではほぼ発見できません。

したがって、アプリケーションにログイン機能があるなら、実際に必要なのは認証付きスキャンです。

認証に対応しているスキャンタイプ

認証は Web Application Scan の機能です。Scanner Console で有効にすると、クロールも能動的なテストも、ログイン済みユーザーとして実行されます。それ以外のエンジン (Network、SSL/TLS、Subdomain Finder、Website Recon、WordPress、Cloud、Kubernetes) は外部から診断する方式のため、認証は使用しません。

スキャンオプション (Scan options) にある Web Application Scan のスキャンタイプは ライト (Light) · ディープ (Deep) · カスタム (Custom) の 3 つですが、認証を有効にするとそのうち 1 つが選べなくなります。コントロールの下に橙色で次のように表示されます。

Light is not available with authentication turned on. Choose Deep or Custom, or turn off authentication. (認証を有効にしている場合、ライトは使用できません。ディープかカスタムを選択するか、認証を無効にしてください)

これは制限というより、製品として筋が通っているということです。ライトは手早く表面を確認するためのスキャンであり、これをセッションと組み合わせても、ログインの先に到達できない浅いクロールに認証情報を消費するだけになります。認証を渡す意味があるのは ディープ です。

ステップ 1 — Scanner Console を開き、認証付きスキャンを有効にする

Infrastructure Security → Vulnerability Scanner を開き、スキャンを実行 (Run scan) をクリックして Scanner Console を開きます。ターゲットを選択し、選択中のスキャンタイプに Web Application Scan が含まれていることを確認します。

スキャンタイプの列をスクロールして、認証付きスキャンのカードを表示します。初期設定では Off です。

これを Enabled に切り替えます。カードが展開され、ログインフォーム、Cookie、ヘッダーの 3 つのタブが表示されます。それぞれ、AlienGate がセッションを取得する方法に対応しています。アプリケーションのログイン方式に合うものを選択してください。各方式については次のセクションで説明します。

ステップ 2 — 認証方式を選ぶ

どれを選ぶか迷う場合は、まずログインフォームから始めてください。ログインはスキャナーが代行し、認証を確認を実行すればログインに成功したかどうかがすぐにわかります。

方式 1 — ログインフォーム

スキャナーはヘッドレスブラウザーでログインページを開き、フォームを検出して認証情報を入力し、送信します。人が手作業で行う操作と同じです。標準的なユーザー名とパスワードによるログインに最適です。

次の項目を入力します。

• ログインページ URL (Login page URL) — 実際にログインフォームがあるページの URL です。http:// または https:// で始まる必要があります。ターゲットのトップページではないことが多く、デモ用ターゲットでは http://0-day.jp/login.php です。
• 専用テストアカウントのユーザー名 (Username) とパスワード (Password)。

入力したら 認証を確認をクリックします (ステップ 3)。

方式 2 — Cookie

シングルサインオン、複数ステップのフォーム、ワンタイムコードなど、自動化しにくいログインフローもあります。その場合は、ご自身でブラウザーからログインし、セッション Cookie をスキャナーに渡してください。スキャナーはすでにログイン済みのブラウザーと同じように動作します。すべてのリクエストに Cookie が付与され、クロールは認証後のページから直接始まります。

次の項目を入力します。

• Cookie ヘッダー (Cookie header) — ログイン済みセッションの Cookie リクエストヘッダーの値全体を、ブラウザーが送信するとおりに貼り付けます。name=value のペアを ; で区切った形式です。例: PHPSESSID=8jhs0rmecss6r2bvx2fcqa3hz1; token=J51Kti3。コピーの手順は、後述の「セッション Cookie の取得方法」を参照してください。
• 確認するページ (Page to verify) — /account や /api/me など、セッションが必須のページを指定します。確認では、このページを Cookie 付きで読み込みます。公開ページはセッションの有無にかかわらず 200 を返すため、確認になりません。

スキャン中に期限切れにならないセッションを使用してください。アプリケーションが一定時間操作がないとログアウトする仕様の場合は、スキャンを実行する直前にログインし直し、テストアカウントのセッションタイムアウトを延ばすことも検討してください。

方式 3 — ヘッダー

JWT、API キー、Bearer トークンなどトークンベースのログインでは、セッションは Cookie ではなくリクエストヘッダーに保持されます。セッションを保持するヘッダー行を貼り付けると、スキャナーがすべてのリクエストに付与します。

次の項目を入力します。

• 認証ヘッダー (Authentication headers) — 1 行に 1 ヘッダーずつ、Name: value の形式で入力します。例:

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...
X-Auth-Token: your-api-token-here

Cookie: の行も使用できます。アプリケーションが Cookie とトークンの両方を必要とする場合は、両者を組み合わせることができます。

• 確認するページ — Cookie の場合と同様に、有効なセッションがあるときだけ 200 を返すページを指定します。

トークンの入手先はアプリケーションによって異なります。ログイン後にブラウザーが送信する任意のリクエストの Authorization ヘッダー (DevTools → Network → Headers で確認できます) か、アプリケーションの API が発行するトークンです。トークンには有効期限があります。JWT の exp クレームを確認し、スキャンが終わるまで有効であることを確かめてください。

ステップ 3 — 実行前に認証を確認する

どの方式にも 認証を確認ボタンがあります。必ず実行してください。数秒で完了し、認証付きスキャンになるか、認証されたつもりのスキャンになるかは、これで決まります。

AlienGate は、入力された内容をそのまま使ってヘッドレスブラウザーでログインし、結果を表示します。

認証結果 (Authentication result) パネルは 4 つの部分で構成されています。

1. 判定 — 認証成功 (Authentication succeeded) または失敗と、その理由が 1 文で表示されます。ログインフォームの場合、スキャナーは 3 点を確認します。アプリケーションがログインページからリダイレクトしたこと、セッション Cookie が設定されたこと、遷移先のページにログインフォームがもう表示されていないことです。例では次のように表示されます。Login accepted: the application redirected to http://0-day.jp/account.php, set 2 cookie(s): PHPSESSID, auth, and the page no longer shows a login form.
2. 到達したページ (Page reached)、タイトル、ステータス、セッション Cookie — 判定の根拠となる情報です。
3. ログイン後にスキャナーが見ているページのレンダリング済みプレビュー。クローラーが最初に訪れる画面です。アカウントページが表示されていれば問題ありません。ログインフォームが再び表示されている、エラーが出ている、「セッションの有効期限切れ」というメッセージが出ている場合は、そのまま実行すると認証なしのスキャンになってしまいます。
4. 確認がヘッドレスブラウザー (スキャンで使用するものと同じ) で行われたことを示す注記。

Cookie とヘッダーの場合は、セッション情報を付けて確認するページを読み込み、そのレスポンスで判定します。セッションが必要なページで、ログインページへのリダイレクトなしに 200 が返れば成功です。

確認の実行中は、Scanner Console から移動したり、ページを再読み込みしたりしないでください。失敗した場合、よくある原因は次のとおりです (可能性の高い順)。ログインページ URL の誤り (フォームが含まれるページである必要があります)、認証情報の入力ミス、Cookie やトークンがすでに期限切れになっている、確認するページが公開ページである、ファイアウォールや WAF によるスキャナーのブロック。最後の点については AlienGate のスキャンはどの IP アドレスから送信されますか？ を参照してください。

ステップ 4 — スキャンを実行する

確認が成功したら、スキャンオプションを設定します (ディープ、リダイレクトの追跡は同一ドメイン、1 秒あたりのリクエスト数は初期値の 100。小規模な環境やレート制限の背後にある環境では下げてください。スロットルされたスキャンは、時間がかかるだけではなくカバレッジに欠落が生じます)。設定したら スキャンを実行 (Launch Scan) をクリックします。

クリックする前に、コンソール下部のサマリーバーを確認してください。選択中のターゲット数 (Targets Selected)、有効なスキャンタイプ数 (Scan Types Active)、資産あたりの平均所要時間、Authenticated の表示、そして合計所要時間の見積もり (Est. Total Time) が並びます。この Authenticated の表示が、このスキャンに認証情報が紐づいていることの最終確認です。表示がなければトグルがオフに戻っており、認証なしのクロールを実行しようとしています。キューに追加されたスキャンには、スキャン履歴 (Scan history) に Authenticated バッジが表示されるので、後から認証なしの実行と区別できます。

これ以降の手順、つまりライブコンソールの監視、検出事項の確認、Issue Tracker への移行は、通常のスキャンと同じです。記事 01 のステップ 9 以降と 記事 02 に従ってください。

認証付きの部分が実行されたかどうかを確認する

完了したスキャンで、次の 3 点を確認します。

• スキャンに Authenticated バッジが付いている。
• 偵察 (Recon) タブとクロールした URL の一覧に、ログインの内側にしか存在しないページが含まれている。アカウントページ、設定ページ、フロントエンドが呼び出す API エンドポイントなどです。同じターゲットを認証なしでスキャンした場合は、一覧がはるかに短くなります。
• 検出事項が、認証後のページやパラメーターを参照している。デモ用ターゲットでは、/account.php?id= のオブジェクト参照や、注文フォームおよびクーポンフォームのインジェクションポイントが検出されるのは、認証付きスキャンのときだけです。

いずれにも当てはまらない場合、スキャン中にセッションが失われています。原因は、多くの場合セッションの期限切れか、クローラーがログアウトのリンクにアクセスしたことです。テストアカウントのセッションを長くして、再実行してください。

セッション Cookie の取得方法 (Chrome)

1. Chrome でテストアカウントを使って通常どおりアプリケーションにログインします。
2. デベロッパーツール (メニュー → その他のツール → デベロッパーツール、または Ctrl + Shift + I) を開き、Network タブに移動します。
3. ログインが必要なページ (アカウントページなど) を読み込み、リクエストが一覧に表示されるようにします。
4. そのリクエストをクリックし、Headers タブを開いて Request Headers までスクロールします。
5. Cookie ヘッダーの値全体をコピーします。PHPSESSID=a765feb13b4112f3d12f3dfa12e; aaid=ad4b654ad48f4d545a64d75ea のような形式です。コピーした値を Cookie ヘッダー欄に貼り付けます。

アプリケーションが Cookie の代わりにトークンを使用している場合は、同じパネルに Authorization ヘッダーが表示されます。その行をヘッダー方式に貼り付けてください。

内部の仕組み

Web の脆弱性スキャンは 2 つのフェーズで構成されます。クロール (ページ、フォーム、パラメーターの検出) と、能動的なテスト (見つかった対象にペイロードを送信) です。両方をログイン済みユーザーとして実行するには、スキャナーにセッションが必要です。

• ログインフォームでは、スキャナーがまずヘッドレスブラウザーでログインを実行し、アプリケーションが設定したセッション Cookie を収集して、以降のすべてのリクエストで使用します。
• Cookie またはヘッダーでは、ログインはすでにお客様が済ませているため、指定されたセッションを使ってすぐにクロールとテストが始まります。

どちらの方式でも、スキャナーはセッションを使うことしかできません。スキャンの途中でアプリケーションがそのセッションを引き続き有効と扱っているかどうかは、スキャナーにはわかりません。事前の確認があるのも、後からクロールした URL 数を見るべきなのも、このためです。90 分のスキャンで 10 分後にセッションが切れると、見た目は完全でも実際には不完全なレポートが出力されます。

クイックリファレンス