 |
≫ |
|
|
|
|
|
|
|
|
| あまりにも親切すぎるエラーメッセージは要注意です。詳細なエラーメッセージは、ユーザーにとっては問題解決に役立ちますが、ハッカーへは侵入の手がかりを与えてしまうことになるからです。 |
ユーザーの誤入力や内部処理に起因するWebアプリケーションエラーに対して、良心的な開発者であれば、問題解決に役立つエラーメッセージをユーザーに伝えようと考えるでしょう。一方で、あまりにも親切すぎるエラーメッセージは要注意です。アプリケーションのエラーを詳細に提示することで、ハッカーに侵入の道筋を与えることにもなりかねないからです。ハッカーは時間をかけてサイトの挙動を調べ、慌てることなく情報の断片をつなぎ合わせながら、サイトの脆弱度合いを把握します。
単なるアプリケーションのエラーメッセージで、一見するとなんら問題がないと思われる情報も、ハッカーにとっては、壊滅的な被害を与えるような攻撃の開始に必要なパズルの最後の一片となる可能性があるのです。 |
|
詳しすぎるエラーメッセージの典型例のひとつが、ログイン画面で認証に失敗したときに表示されるメッセージです。普通に考えれば、「入力されたユーザーIDが見つかりません」と、「パスワードが間違っています」という入力エラーをメッセージとして区別して表示したほうが、ユーザーには親切でしょう。確かにそうなのですが、このようなエラーの表示は、ユーザーよりもハッカーを助けてしまうのです。
ハッカーがWebアプリケーションへの侵入を試みていると仮定します。ハッカーは、サイトで使用されている実際のユーザーIDやパスワードを知りませんから、「ブルートフォース（総当り）」攻撃や「辞書」攻撃を試みるでしょう。一般的なユーザーID（admin、user、guestなど）と一般的なパスワード（password、admin、Elvisなど）とをペアにしたリストを使った方法です。Webサイトに対して、ユーザーIDとパスワードの組合せをすべて試す過程で、上手くいく組み合わせが見つかる可能性もあります。実際の電子辞書のような大規模なリストを使用した場合、その組合せは億単位になるでしょう。たとえハッカーが自動化ツールを使用したとしても、有効な組み合わせに到達するまでには、週あるいは月単位の期間がかかるはずです。
しかし、ユーザーIDとパスワードのどちらが無効かをWebサイトのエラーメッセージとして表示してしまうと、ハッカーの仕事量はかなり軽減されます。ユーザーとパスワードの入力に対して「パスワードが無効です」とエラーメッセージが表示されたとしたら、攻撃リストにある他のユーザーIDを調べる必要がなくなるからです。推測したユーザーIDがシステムに存在することを把握したハッカーは、パスワード攻撃のみに集中するでしょう。攻撃リストが5,000件のユーザーIDと5,000件パスワードで構成されているとすると、IDもパスワードも分からなければハッカーは2,500万通りのログインを試さなければならないのに対して、ユーザーIDが判明することで、わずか5,000通りのログインを試すだけで済んでしまいます。5,000通りのログインを試すだけなら週単位ではなく時間単位で終了すると考えられ、サイト管理者が異常に気がつく前に、Webサイトに侵入される可能性が高くなります。
|
|
ユーザーの入力エラーに対して、エラー処理を担当している開発者が取るべき最善の措置は、ユーザーIDかパスワードのどちらが合っていなくても、表示するエラーメッセージを同じにすることです。たとえば、「ユーザーIDまたはパスワードが無効です」のように表示するとよいでしょう。このようなエラーメッセージは、ログイン認証情報を再度入力する必要があることをユーザーに知らせるには十分であり、一方で、総当り攻撃を試みようとするハッカーに新たな手がかりを与えません。
|
|
先ほども述べたように、ユーザー向けのエラー処理では詳細情報は提供しないほうが賢明です。とくに、アプリケーション内部でエラーが発生した場合、詳細情報を見せないことがより重要となります。アプリケーションエラーの原因は、必要なデータベースやWebサービスが使用できない、コンポーネントのライセンス期限が切れているなどさまざまです。コードのバグが原因となる場合もあります。原因が何であれ、アプリケーションエラーの詳細はユーザーに提供しないことが重要です。
ハッカーは詳細な情報を喉から手が出るほどに欲しがっています。データベースでのエラーを例にすると、詳細なコンポーネントエラーを表示しただけで、使用しているデータベースの種類、バージョン、データベースが動作しているオペレーティングシステム、使用しているWebサーバのほか、Webアプリケーションの一部のソースコードさえ、ハッカーは把握できてしまうでしょう。これらの情報の断片を重要なヒントとしてハッカーはWebサイトを攻撃します。たとえば、使用しているデータベースが、エラー処理からMicrosoft SQL Server 2000であることがハッカーに知られてしまえば、ハッカーはインターネットを検索してMicrosoft SQL Server 2000のセキュリティの脆弱性を調べるでしょう。一部のアプリケーションは、ユーザーが問題の原因を特定できるように、問題のファイルのパスやテｰブルの行や列の名前まで、エラーメッセージとして提供しています。このようなエラー処理は、悪意ある目的に利用できる多くの情報をハッカーに提供してしまうことになります。
多くのWebサイトは、丁寧なメッセージにコンポーネントのエラーコードを組み合わせたエラーメッセージを表示することで、ユーザーに対して親切な情報を提示しつつ、詳細な情報開示を避けるように工夫しています。たとえば、「エラーが発生しました。技術サポートに連絡してください。エラーコードは123-456-789です」といったメッセージです。しかし、このようなエラーメッセージは、前述のエラーメッセージと同じ理由で、それほど適切ではありません。その理由はハッカーに「123-456-789」というエラーコードを与えているからです。アプリケーションのエラーコードを記載したドキュメントがインターネット上に存在する可能性があり、もしも存在すればハッカーは検索によって情報を得てしまうでしょう。
|
|
一部のWebアプリケーションは、エラーが発生すると、エラー処理の過程でユーザーに表示すべき内部エラーコードを作成します。たとえば、データベースレイヤでアプリケーションエラーが起きると、「技術サポートに連絡してください。エラーコードは01です」のようなメッセージを出力します。また、コンポーネントのライセンスでアプリケーションエラーが起きた場合は、メッセージに表示されるエラーコードが「02」になるかもしれません。このようなエラー処理方法は、インターネットを検索しても内部コードの意味は分かりませんので、前述の方法に比べてセキュリティは高いといえるでしょう。しかし残念ながら、このエラー処理方法も安全ではないのです。
何がセキュリティ上の問題かというと、エラーの内容ではなく、エラーを区別して示しているという点にあります。
|
|
エラー処理からもれてしまうわずかな情報でも安全を脅かす恐れがあります。もちろん、たったひとつのエラーメッセージに、ハッカーがシステムに侵入するために必要なすべての情報が含まれているわけではありません。ハッカーはシステムを一発で仕留めようとするのではなく、何ヵ所もの小さな穴を突いてきます。アプリケーションのエラー処理が不適切だと、そこで示されたわずかな手がかりが、ハッカーにとってはシステムの脆弱性を突くだけの十分な情報となるのです。
|
|
このようなセキュリティの脅威を避ける一案として、システムで発生したすべてのエラーに対して、単に「エラーが発生しました」という一般的なメッセージの表示に留めておく方法が考えられます。アプリケーションエラーの詳細は表示されませんのでエラー内容も区別できません。ハッカーが利用できる情報は何もありません。ただ、このエラー処理方法は、セキュリティ上は非常に堅牢ですが、開発者や技術サポート担当者に対しても情報を与えてくれません。ユーザーがアプリケーションエラーに遭遇したとしても、アプリケーション開発者が問題の再現やデバッグに必要とする情報を、ユーザーは報告することができません。
セキュリティ上も安心で、かつ、エラー部位の特定にも有効なエラー処理を行うには、インシデントのトラッキングシステムの導入が有効です。アプリケーションは、エラーが発生したら、エラー状態の詳細なログを必ず記録するように設計しておきます。それぞれのエラーには固有のトラッキングIDを割り当て、Webブラウザからはアクセスできないデータベースやディレクトリのようなサーバの安全な場所に保存します。また、ユーザーには、エラーメッセージをトラッキングIDと合わせて表示します。ユーザーは表示されたトラッキングIDを技術サポートに報告すれば、技術サポートは安全なサーバから詳細なログを参照して詳細を把握することができます。このエラー処理方法であれば、アプリケーションの開発者には詳細な情報が提供されますが、ユーザーやハッカーは詳細な情報を得ることはできません。
このようなインシデントのトラッキング手法は、アプリケーションエラーのタイプとエラーの挙動との対応付けが困難である、という要件も満たします。エラーが起こるごとに異なったトラッキングIDを割り当てるようにすれば、同じエラーメッセージが二度表示されることがありません。この手法はエラー応答からパターンを特定できないため、前述のようなあらゆるエラーに対してたったひとつのエラーメッセージを表示する方法と同じくらい安全です。エラー処理のセキュリティをさらに高めるには、連続番号でなく、完全な乱数またはグローバル一意識別子（GUID）をトラッキングIDに使用します。こうすることで、推測しやすいトラッキングIDを使った「なりすまし」攻撃の実行を防げます。
|
|
Webアプリケーションでエラーが発生した場合、ユーザーにフィードバックすべき情報を決めることは簡単ではありません。開発者ができるだけ分かりやすいエラー処理を心がけたとしても、ユーザーに役立つ情報はハッカーのシステム攻撃にも役立つことになるため、開発者の親切心は裏目に出てしまいます。逆に、開発者があいまいさに徹したエラー処理を行うと、エラーに遭遇したユーザーから技術サポートに何ら情報が提供されないため、アプリケーションエラーの原因を解決することが難しくなってしまいます。
アプリケーションのエラーメッセージの作成にあたって、以下のようなシンプルな指針を提案します。
- 無効なパスワードなどユーザー入力に起因するエラーが起きた場合は、エラーの要因を区別 しない一般的なエラーメッセージを表示するようにします。
- アプリケーションコード内でデータベースエラーのようなエラーが起きた場合は、トラッキング 番号を併記した一般的なメッセージを表示するようにします。技術サポートは、このトラッキング 番号から、問題を解決することができます。
このようなガイドラインに従うことで、エラー処理メッセージからアプリケーションに関する情報を得ようとするハッカーの企みを防いでください。
|
|
| ［1分アンケート］ |
|
|
|
|
|
|
印刷用画面へ
