脆弱性コラム - 第1回
サイト脆弱性をチェックしよう！-- 第1回：ウェブアプリケーションに潜む危険
ウェブアプリケーションに潜む危険は数多くあるが、これまでのセキュリティ対策で指摘されてきたのは脆弱性の種類から見た危険性とその対策だった。たとえば、クロスサイトスクリプティングの脆弱性とは何か、SQLインジェクションの脆弱性とは何か、そしてそれらへの対策とは……。これらについては、既に的確な解説をウェブ上で見つけることができるので、この連載では改めてその視点での解説はしない。
この連載では逆の視点から、つまり原因となる行動に焦点をあてて、ウェブアプリケーションにおける脆弱性を考えていきたいと思う。
まず、ウェブアプリケーションの脆弱性が発生する原因だが、「既製品の脆弱性」および「カスタマイズアプリケーションの脆弱性」の大きく2つに分類される。
さらに、既製品の脆弱性は「既知の脆弱性」と「市販製品の設定ミス」の2つに、カスタマイズアプリケーションの脆弱性は「設計時に発生する脆弱性」「コーディング時に発生する脆弱性」の2つに分類できる。
| 既製品の脆弱性 |
|---|
| 既知の脆弱性 市販製品の設定ミス |
| カスタマイズアプリケーションの脆弱性 |
| 設計時に発生する脆弱性 コーディング時に発生する脆弱性 |
既製品の脆弱性については無視することはできないが、これらについてはメーカーなどから正しい対応策が公開されているものがほとんど。ユーザーとして、あるいはシステム構築者としてベンダー各社からの最新情報を入手して対策を行うことが最善の方法となる。
一方、カスタマイズアプリケーションの脆弱性は開発者が修正することが基本的な対策となる。もちろん、ウェブアプリケーション用のファイアウォールを導入するといった別解もあるが、そのような製品を扱うためにも“なぜ脆弱性が生じるのか”を理解しなければ正しい設定は行えない。そのために、どのような要因から脆弱性が生み出されるのかを認識しておく必要があるだろう。
そこで今回は、紹介した脆弱性のパターンのうち、「設計時に発生する脆弱性」について解説してみたい。
設計時に発生する脆弱性とは？
開発の初期段階からセキュリティ対策を行えば、コストを抑えられると言われている。しかし、既存の対策方法の多くは、コードレベルの修正方法に終始していて、実際に設計段階で何を行えばよいか分からないのが現状だろう。そこで、まずは設計時に作りこんでしまう脆弱性と、設計時のセキュリティ対策について考えてみたい。ここには大きく分けて2つの脆弱性が作られる可能性がある。ひとつは「画面遷移に関係する脆弱性」であり、もうひとつは「機能設計に関係する脆弱性」である。それぞれに対応する具体例は、以下のとおりだ。
| 画面遷移に関係する脆弱性 |
|---|
| 強制ブラウズ クロスサイトリクエストフォージェリ |
| 機能設計に関係する脆弱性 |
機能の悪用
|
画面遷移に関係する脆弱性
ウェブアプリケーションは、複数の画面を遷移し、さまざまな処理を行う。このとき利用しているHTTPは、1回のアクセスごとに通信が完結するステートレスなプロトコルであり、各処理が正常に行えるかどうかを無視すれば、各画面にアクセスすること自体はユーザーが自由に行うことができる。このため、ユーザーの状況（セッション）をアプリケーションが把握し、制御する必要がある。しかし、制御が不適切であればログインしていないユーザーが機密情報を表示する画面にアクセスしたり、ユーザーが意図しない情報の更新を行わせることなどが可能になる。
このような画面遷移の設計において作りこまれてしまう脆弱性には、「強制ブラウズ」「クロスサイトリクエストフォージェリ」などがある。
まず「強制ブラウズ」は、許可されていないはずのページにアクセスできてしまうという脆弱性だ。これは設計の段階で、どういった状況（たとえば、ログインした状態）や、どういうものしかアクセスできないのか（たとえば、ブラウザからはアクセスできないが、アプリケーションからは読み込める）と言うことを明確にしていないために発生してしまう。
対策としては、アクセスできる条件（ファイルへのアクセス権を含む）を明確にし、その条件に基づいて設定および構築を行う必要がある。
また「クロスサイトリクエストフォージェリ」は、ログインした状態で処理を行うURLに直接アクセスすることで、意図しない処理が行われてしまう脆弱性だ。たとえば、電子商取引サイトにこの脆弱性があり、ログインした状態で悪意のあるサイトにアクセスした場合、意図せず商品購入を行われる可能性がある。
これは、ログインした状態であれば、どんな状態であっても処理が行われることが原因だが、設計の段階で処理が行われる条件を明確にし、その条件に基づいて構築する必要がある。
これらの脆弱性の対策では、どういった状況でこの画面が呼び出されるのか、その状況を把握するにはどうすればよいかを十分に検討する必要がある。
不十分な機能設計による機能の悪用
アプリケーションには、商品を購入したりメールを送信したりするさまざまな機能がある。これらの機能を実現するためにアプリケーションでは、データをデータベースに追加、更新、検索したり、外部プログラムの呼び出しなどをおこなっている。また、状態を把握するために、CookieやHiddenフィールドを使用している。このような実装する機能や、CookieやHiddenパラメータに格納する情報をセキュリティの観点から十分に考慮していないと、機能を悪用されることがある。
実装した機能によっては、いろいろなことに悪用できるものがある。たとえば、機能の悪用には、「メール送信機能」「パスワードエラー通知機能」「バックドアとデバッグオプション」などがある。
「メール送信機能」の悪用では、たとえばアンケート結果をメールで送信する機能を搭載したアプリケーションがあったとしよう。このアプリケーションは送信先を Hiddenパラメータで指定するような設計になっていた場合、攻撃者がこのアプリケーションを使ってSPAMメールを送信することができる。
対策としては、送信先をパラメータで指定するのではなく、設定ファイルで指定することで悪用することを防ぐことができる。
また「パスワードエラー通知機能」の悪用では、たとえばログイン時にパスワードを間違っていたら「パスワードエラー」と表示し、ユーザーIDが間違っていたら「存在しないユーザーです」と表示するアプリケーションが考えられる。
この場合、攻撃する側にとって存在しているユーザーが判明するため、ブルートフォース攻撃（パスワードとユーザーIDの組み合わせを総当りでログイン試行する攻撃）を短時間に行うことができるようになる。
どんなメッセージでも、攻撃者には有用な情報となるため、可能な限りメッセージは内部の情報が分からないようにすべきだろう。特にエラー内容の詳細を画面に表示することはアプリケーション内部の重要な情報を攻撃者に与えることになる。
エラーメッセージは内部で何が起こったかを記述するのではなく、例えば「エラーが発生しました。再度実行してください」といった簡単なものを表示し、エラーの詳細は安全な場所に保存されるログに出力するようにするべきだ。
この例の場合であれば、パスワードおよびユーザーIDのどちらが間違っていても、「ユーザIDもしくはパスワードが違います」と同じメッセージを表示することで、より安全なアプリケーションになる。
さらに「バックドアとデバッグオプション」の悪用は、たとえばシステムの障害が発生した場合のために、デバッグオプションやバックドアをあらかじめ準備しておくことがある。このとき、デバッグモードを起動するためのパラメータやバックドアを利用されると内部情報が漏えいしたり、サーバに侵入されることになる。
このような機能は悪用されるので、極力実装しないことが望ましいのだが、デバッグに便利であるため、機能として搭載したいときがある。この場合、デバッグモード、バックドアの起動を制御するパラメータを利用するのではなく、設定ファイルに記述した内容をもとに起動を制御することで、デバッグモード、バックドアを安全に利用することができる。
まとめ
今回、紹介した脆弱性はすべて、設計時にその機能を実装することにより、どのようなリスクがあるかを十分に検討し、リスクを軽減するための機能を設計／実装することで悪用を防ぐことができる。また、取り扱う情報についても漏えい、改ざんされた場合にどのような被害があるのか十分に検討し、被害にあうと損失が大きい場合には、被害を最小限にできる設計をしておく必要がある。
設計時に機能、取り扱う情報にどのような脅威があり、どの程度重要なものなのかを検討し、その脅威に対して重要度に見合った対策を行うことで、より安全なアプリケーションを設計、構築することができるようになる。
次回は、コーディング時に発生する脆弱性について解説したいと思う。
イベント・セミナー
ニュース・キャンペーン
AppScanに
関するお問い合わせ
テクマトリックス株式会社
東京本社ネットワークセキュリティ事業部
第3営業部
セキュリティプロダクツ営業2課03-4405-7814
- メールでのお問い合わせ
- watchfire@techmatrix.co.jp