情報漏洩

情報漏洩の概要

サイトが誤って機密データを利用者に公開してしまう状況を、情報漏洩（別名データ漏洩）と言います。環境によっては、次のような情報が攻撃者に渡る可能性があります。

• 利用者に関する情報（例：ユーザー名や金融情報）
• 機密の事業情報
• サイトの基盤や構成の詳細

機密データの漏洩は、利用者や事業情報が漏れるのと同様に重大な影響を及ぼすことがあります。一部の情報は有用な場合もありますが、それが攻撃の足がかりとなり、他の重要な脆弱性の発見につながる恐れがあります。取得した情報を基に、高度かつ重大な攻撃が組み立てられる可能性があります。

通常のウェブ閲覧をしているだけでも、意図せず重要な情報が漏れる場合があります。しかし、情報漏洩の原則として、攻撃者はサイトに対して異常または悪意ある動作を働くことで情報の漏洩を引き起こします。その際、サイトのレスポンスを丹念に検証し、異常な挙動がないか確認します。

‍

情報漏洩の脆弱性はどのように発生するのか

情報漏洩の脆弱性は様々な状況で発生しますが、一般的には以下のようなケースに分類されます。

• 開発環境などでプライベートデータを公開内容から削除するため、時折マークアップ内に技術者向けのコメントが残される場合がある。
• サイトの設定や関連開発が不十分な場合、トラブルシューティングや解析情報が攻撃者に機密情報取得の手がかりを与えてしまう。デフォルト設定を使用しているサイトでは、詳細なエラーメッセージが表示され、脆弱になりやすい。
• アプリの挙動や設定に欠陥があると、異なるエラー条件で異なるレスポンスが返され、攻撃者が重要な情報（例：利用者パスワード）を特定できる恐れがある。

情報漏洩の脆弱性の影響

サイトの目的や、攻撃者が入手できる情報の種類によって、情報漏洩の脆弱性は即時的な影響と間接的な影響の両方を及ぼす可能性があります。

特定の状況では、たった一度でも機微な情報が漏れるだけで、対象組織に大きな影響が及ぶことがあります。例えば、オンラインショップで顧客のMastercard情報が漏洩すれば、重大な結果を招く恐れがあります。

一方、ディレクトリ構造や使用中の外部システムの情報が漏れても、直ちに影響が現れないこともあります。しかし、この種の情報が不正な手に渡れば、多様な攻撃の足がかりとなります。攻撃者がこの情報をどのように利用できるかにより、問題の深刻さが決まります。

情報漏洩の事例

• 機密データの取り扱いミス

ユーザー名やパスワード、内部IPアドレスなどの機密情報をコード内に直接記述することは、よくあるミスです。こうした情報は多くの場合、本番アプリに含まれているため、攻撃者はページのソースを確認するだけで容易に入手でき、ウェブアプリのセキュリティに悪影響を与える恐れがあります。（例：ページを右クリックして「ページのソースを表示」を選ぶ方法など）

• バナーキャプチャ

バナーキャプチャ攻撃では、攻撃者が対象フレームワークについての情報を収集するための問い合わせを行います。サーバのバージョン、PHP/ASP.NETのバージョン、OpenSSHの形式など、フレームワークに関する詳細情報が漏れる可能性があります。

多くの場合、バナーキャプチャで得られる情報は、攻撃の二次段階で攻撃者に有利となるもので、直接的な機密情報とは異なります。例えば、対象がサーバに導入されたPHPのバージョンを漏らし、そのバージョンがリモートコード実行（RCE）攻撃に対して脆弱である場合、攻撃者はその欠陥を利用してサイトへ侵入する可能性があります。

• ファイル名とパスの漏洩

ウェブアプリは、時折ファイル名やディレクトリ名を公開してしまい、システム設計の手がかりを与える場合があります。これは、利用者の入力の不適切な処理、特定のバックエンド事情、またはサーバ設定の不備などが原因となることがあります。こうした情報は、アプリのレスポンス、エラーページ、トラブルシューティング情報などに含まれる場合があります。

ウェブアプリがファイル名やパスを漏らしているか確認するため、攻撃者は意図的に様々なリクエストを送る簡単なテストを行うことができます。例えば、以下のリクエストを送ると、403（Forbidden）のレスポンスが返されます：

https: //www.example.com/ %5C.. /%5C../%5C../%5C../%5C../%5C../ etc/ passwd

しかし、続けて送ったリクエストでは、404（Not Found）のレスポンスが返されます：

https: //www.example.com/ %5C../%5C../%5C../%5C../%5C../ %5C../ etc/ doesntexist

最初のリクエストで403 Forbiddenが返され、次で404 Not Foundとなることから、対象のファイルは存在していると判断できます。攻撃者は、こうしたレスポンスを基に、サーバの設定や特定のディレクトリ・ファイルの有無を見極めることができます。

• ソースコードの漏洩

ウェブアプリのバックエンド環境のソースコードが公開されると、ソースコード漏洩の問題が発生します。コードを解析し、脆弱性、ハードコードされたユーザー名・パスワードの組み合わせ、またはAPIシークレットキーなどを探し出すことで、攻撃者はアプリの内部動作を理解する手がかりを得ることができます。漏洩したコードの量により問題の深刻さは変わりますが、ソースコード漏洩が発生すると、攻撃者はコードに直接アクセスできるため、ブラックボックステストではなくホワイトボックステストに近い状況となります。

情報漏洩の防止

情報漏洩に関するセキュリティの懸念は、一見些細に思えるかもしれません。しかし、公開ページでの簡単な情報抽出や基本的なテストにより、攻撃者は対象の重要な機密情報を入手する可能性があります。

こうした問題は常に対処すべきであり、対策は比較的容易です。以下の提案は、オンラインアプリを一般的な情報漏洩の脆弱性から守るためのものです：

• ウェブサーバがレスポンスヘッダーや基盤情報を送らず、バックエンド技術のバージョンや設計の詳細が漏れないよう確認する。
• サーバのオープンポートで動作するサービスが、そのソフトウェアやバージョン情報を漏らさないようにする。
• すべてのウェブサーバ、サービス、アプリにおいて、攻撃者からのアクセスを防ぐための適切なアクセス制御と認証を設定する。
• ウェブアプリがエラーを出す際、特定の情報が漏れないよう、すべての例外処理が正しく行われていることを確認する。
• ログイン情報、APIキー、IPアドレス、その他の機密情報をコード内にハードコードしないこと。コメント内の氏名も含まれる。
• ウェブサーバに設定される各種ファイルのMIMEタイプが適切であることを確実にする。
• 必要のないファイルや機密情報、その他のデータをウェブサーバにアップロードしない。
• 作成、変更、閲覧、削除など各リクエストに対して、適切なアクセス制限が設定され、不必要な権限昇格を防いでいることを常に確認する。
• 攻撃者を混乱させるため、アプリが利用者の情報を正しく処理し、存在しないまたは禁止されたリソースに対しては統一されたレスポンスを返すようにする。
• バックエンドコードは、すべての特殊ケースに対して十分な検証を行い、機密情報の漏洩を防ぐよう実装する。
• ウェブサーバは、発生した例外を抑制し、汎用的なエラーページを返すよう設計する。
• アプリがデフォルトのサイトページを表示し、サーバ上でディレクトリ一覧表示が無効になっていることを確認する。