"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。

ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。

この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。

情報露出の把握

情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。

多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。

機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。

一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。

情報漏洩の危険性を理解する

アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。

攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。

OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。

情報露出をなくす

情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。

アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。

ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。

ウェブアプリを沈めないために

第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。

同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。

アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。

今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]