強制閲覧攻撃

強制閲覧とは何か？

強制閲覧攻撃とは、攻撃者が推測や試行を繰り返すことで、本来アクセスが制限されるべきページやサーバ資産に不正にアクセスを試みる攻撃手法です。通常、ユーザーがログインする際、webアプリは正当な権限を持つユーザーのみが特定の領域やページにアクセスできるよう認証を行います。しかし、強制閲覧攻撃は、正しい認証情報を提示せずに、本来はアクセスできない領域や非公開部分にアクセスしようとするものです。

攻撃者が対象のURLを既に把握している、または推測できる場合、強制閲覧は非常に効果的となります。未認証のユーザーは、ブルートフォース攻撃を用いて、本来公開されないディレクトリ名やファイルを取得し、隠されたサイト機能や情報を探し出す可能性があります。この攻撃を防ぐためには、利用者に表示されるページに限らず、webアプリ内のすべてのページへのアクセス権限を適切なレベルに限定する必要があります。

管理者専用ページ、セキュリティログ、設定ファイル、サンプルアプリ、ログ、テスト結果、一時ファイルなど、攻撃者にとって価値のある機密文書が存在する場合があります。データベース情報、他の重要箇所へのパス、ホスト名、パスワード、隠されたサイト情報、webアプリ内部情報など、機微な情報が含まれていることも少なくありません。

また、ファイルやディレクトリは通常、一般的な場所に保存され、標準的な命名規則が用いられるため、攻撃者はそれを頼りにブルートフォース攻撃を仕掛けることができます。もしwebサーバ内に、適切なアクセスや認証ルールに基づいて保護されていないファイル、ディレクトリ、またはURLが存在すれば、強制閲覧攻撃の成功率は高まります.

‍

強制閲覧の手法

強制閲覧攻撃には、手動型と自動型の2種類が存在します。いずれの場合も、攻撃者が推測を繰り返すブルートフォース攻撃の一形態です。

• 手動型

攻撃者が数字のローテーションなどを用いたり、ディレクトリ名やファイル名を正確に推測してアドレスバーに入力する場合、これを手動型強制閲覧と呼びます。手動で問い合わせを送信する頻度に限りがあるため、自動ツールを用いた攻撃よりも手間がかかります.

• 自動型

自動型強制閲覧攻撃では、ツールを用いてサイト上の存在するディレクトリやファイルを検出します。不正なファイルが数多く隠されていたとしても、専用のスキャナーはそれらを見逃しません.

膨大な候補のページ名を一括でチェックし、その結果をサーバに送信するツールが利用されます。また、各ページリクエストに対応するURLも記録され、その後、攻撃者は手動で有効なページを確認することが可能となります.

攻撃の仕組み

標準ユーザーや管理者など利用者が限られているサイトでは、強制閲覧が問題となるケースが多々あります。各ユーザーはログイン後、自分専用のメニューや設定にアクセスしますが、これらのメニューが案内するページが十分に守られていなければ、誰かが正当なページ名を推測し、そのURLに直接アクセスする恐れがあります.

以下に、物理的な手法と自動化ツールを用いた手法、2つの例を示します.

例 1

この例は、URL内における手動かつ局所的なリソース識別を利用した、予測可能なリソースロケーション攻撃の手法を示します。下記のURLは、user1がオンラインカレンダーにアクセスする場所です:

www.site-example.com/clients/calendar.php/user1/20070715

このURLにはユーザー名（'user1'）と日付（mm/dd/yyyy）が含まれています。もし攻撃者が強制閲覧攻撃を実行すれば、以下のように別の利用者のカレンダーにもアクセスできる可能性があります:

www.site-example.com/clients/calendar.php/user6/20070716

他の利用者のカレンダーにアクセスできた場合、攻撃は成功と判断されます。このような状況は、認証システムの脆弱な設計に起因しています.

例 2

この例では、ツールを用いて静的なディレクトリおよびファイル名の一括探索攻撃を行います.

Niktoのようなスキャナーは、既知のリソース情報を基に、存在するファイルやディレクトリを探し出すことが可能です。例えば:

/framework//secret word//logs//administrator//test/

もしツールが「HTTP 200」の応答を受け取れば、そのリソースが存在し、有用な情報が含まれている可能性があるため、詳細な確認が必要です.

強制閲覧の要因とは

強制閲覧攻撃が発生する原因について尋ねる声は多くあります。安全設定の不備が、その主な原因となります。webアプリの一部が、不適切な設定や構成ミスにより十分に守られていない場合に発生します.

サブシステムやアプリの構成ミスによって脆弱性を持つ場合もあります。プログラム、テスト用の設計書やスクリプト、あるいはwebサーバのデフォルトユーザーが提供する不必要なサービスなどが例として挙げられ、これらの公開された機能が攻撃者にシステムへのアクセスを許してしまう原因となります.

安全設定の不備は、以下のような攻撃手法で狙われることがあります。なお、ブルートフォース攻撃や強制閲覧が含まれます:

• サービスの漏洩
• コードインジェクション
• コマンドインジェクション
• 認証情報の露出
• XSS

強制閲覧を防ぐには

強制閲覧攻撃は、適切なアクセス制御と、アプリのURL空間のホワイトリスト化という2つの対策で防ぐことが可能です.

ユーザーには、権限に応じたアクセスのみを許可する仕組みを整える必要があります。webアプリファイアウォール (WAF) は、認証ルールを適用することでURLレベルの攻撃から守るための優れたAPIセキュリティ対策です.

あらかじめ安全な許可済みURLのみへのアクセスを許すホワイトリストを作成することが重要です。これに含まれないリクエストは自動的に却下され、これらのURLはアプリの基本構成要素として管理されます.

このホワイトリストを手作業で作成・維持するのは手間がかかります。WAFは、予測されるトラフィックの解析や実際のURL空間の把握を通じて、自動的にホワイトリストを構築・運用することができ、一般的に弱いディレクトリやファイルのリストアップも強制します.

セキュリティの欠陥により、優れたWAFであっても強制閲覧攻撃に対して完全に防御できない場合があります。しかし、WAFの機能性を高め、通常の攻撃の発生頻度と影響を低減するためのセキュリティ設計の方法も存在します.

プロジェクト初期の段階では、データベースサーバとwebサーバが同一ホスト上に存在するシンプルな1層または2層のwebアプリモデルが有用です。しかし、これには単一障害点が存在するため、本稼働環境としては適さないことが多いです。総じて、マルチ層またはN層構成にすることで単一障害点を回避し、各機能を個別のサーバに分離することでコンパートメンテーションが実現できます.

パフォーマンス、機能性、可視性、一貫性を向上させるため、ほとんどのアプリではWAFを負荷分散装置の背後に配置するのが理想的です。WAFはどこにでも設置可能ですが、保護対象のアプリに最も近い場所に配置することで、より効果を発揮します.