これまで3回にわたり、富士通が考える情報セキュリティ対策ソリューションの全体像と、3個のソリューションレイヤの中から組織規定レイヤおよびインフラレイヤのセキュリティソリューションについてご紹介してきました。4回目となる今回は、ソリューション体系で最上位に位置するアプリケーションレイヤから、アプリケーションセキュリティ設計構築支援のソリューションをご紹介します。
インターネットの普及とそれに伴うWebベースのアプリケーションの拡大は、アプリケーションセキュリティの従来までの考え方に大きな変革を迫ることとなりました。従来の一般的なコンピュータシステムは閉じられた環境であり、そのシステムを利用する利用者も限られていました。このような環境では、利用者は基本的に信頼できるという前提で運用することができます。利用者が悪意と高度な技術をもって不正な操作を試みるという危険性は、多くの場合無視できるほど小さいものでした。
しかしながら、今日のWebアプリケーションにおいては、この前提は成立しなくなりました。インターネットにおいては、ネットワークにWebサーバを接続した瞬間から、全世界からそのサーバにアクセスできるようになります。ここでは利用者は信頼できるという前提を置くことはできません。このような環境では、悪意を持ったいかなる操作に対しても、正常に動作するだけの堅牢性をサーバは持っていなければなりません。04
今回は、一般的なアプリケーションセキュリティの考え方と、主にWebアプリケーションにおけるセキュリティ対策の方法についてご紹介します。
１．１ アプリケーションのセキュリティ
アプリケーションにおけるセキュリティを正確に定義することは簡単ではありません。しかし、あえて一言で言えば「『利用者がしてよいこと』以外のことができないこと」を達成することだと考えると分かりやすいでしょう。例えば、ネットバンキングのシステムで、自分の口座の残高を確認することは「利用者がしてよいこと」です。しかし、同じシステムで誰か他の利用者の口座の残高が確認できてしまっては問題です。このようなことを禁止し、絶対にできないことを保証するのがアプリケーションのセキュリティです。
ここで、「利用者がしてよいこと」をコンピュータの世界では「利用者権限」と呼びます。利用者は、あらかじめシステムで決められた利用者権限に従って、その権限に許可された操作だけができるようになっています。
また、利用者が「できること」と「できないこと」をコンピュータシステム上で制御することを「アクセス制御」と呼びます。従って、最初の「『利用者がしてよいこと』以外のことができないこと」という言い回しは、コンピュータ用語を使って書き直すと、「利用者権限に基づいて、アクセス制御を実施すること」と表現できます。
１．２ 障害（バグ）と脆弱性（セキュリティホール）
実際にシステムを設計する際には、アクセス制御は下のような表を作って考えます。縦軸左側が利用者の種類、横軸上側がそれぞれの利用者に許可される利用者権限です。例えば、コンテンツ作成者（Webコンテンツを作成する担当者）は、サーバ上のデータを読んだり、コンテンツ更新のために新しいデータを書き込むことはできますが、システムを停止することは許可されていません。
このような設計に従ってシステムは開発されるのですが、実際にはミスなどにより、設計どおりには動かないシステムになってしまう場合があります。このとき、「できなければいけないことができない」、つまりこの表でいうところの「○」が「×」になってしまっているような状態のときは、何かの操作ができないという、一般的な障害（バグ）となります。
一方、「できてはいけないことができる」、つまりこの表で「×」のところが「○」になってしまっている場合には、これがセキュリティ上の脆弱性（ぜいじゃくせい）、つまりセキュリティホールとなります。このように、システムの障害と脆弱性は、本質的には同じシステム開発上の品質の問題なのです。
１．３ 脆弱性を生まないためには
アプリケーションの品質を上げるために、一般にはテストを実施します。障害を除去するという観点で見ると、テストは「できることを確認する」というチェックが中心になります。できること（できなければいけないこと）を洗い出すのは比較的簡単なので、障害の有無をチェックするためのテストを計画するのは、そう難しくありません。
これに対して、脆弱性を除去するためには、「できないことを保証する」テストが必要になります。この場合、できてはいけないことの内容は事実上ほぼ無限に考え出すことができ、チェックするべき項目（テストケース）を網羅的に洗い出すことは非常に困難です。このため、脆弱性の除去については、テストの実施で安全性を保証することは現実的ではありません。
従って、アプリケーションのセキュリティ確保のためには、開発後のテストだけではなく、設計、開発、構築、運用のシステムのライフサイクル全体で、セキュリティに対する一貫した考慮と対策を実施する必要があります。
１．４ アプリケーション設計時の留意点
アプリケーションの設計時に、セキュリティについて考慮すべきことは多数ありますが、一般的に通用するいわば「セキュリティの原則」をいくつか挙げることができます。
【原則１】セキュリティ機能は保証されている方法に任せる（むやみに自作しない）
アプリケーションを開発する場合、そのアプリケーションが動作するプラットフォームのOSやミドルウェアなどが、アクセス制御やセッション管理などのセキュリティ機能を持っている場合があります。このような場合は、可能な限りこれらの機能を利用することを検討するべきです。世の中で広く使われているOSやミドルウェアは、すでに長い時間と多くのサイトによって、その安全性が検証され、またセキュリティホールの修正が行われています。同じ信頼性を自作のアプリケーションで実現することはほぼ不可能です。
【原則２】セキュリティ制御が「必ず実施される」ことを保証する仕組みを考慮する
セキュリティ制御の仕組みは、回り道をして回避されてしまうようでは効果がありません。セキュリティ制御が必要な場面すべてに対策を一つずつ実施する方法もありますが、理論的にここを抑えれば必ず実施されるというポイントを見つけ、そこでセキュリティ制御を実施することができれば、信頼性の高いセキュリティ対策を効率的に実施できます。例えば、入出力を一つのモジュールやクラスに集中させ、そこでセキュリティ制御を行うのはよい方法です。
【原則３】例外を洗い出そうとせず、例外をすべて除外する
例えばアプリケーションへの入力値が正しいかどうかをチェックするとき、問題が起こるような入力をチェックして除外するようにアプリケーションを設計してしまいがちです。逆に、正しい入力かどうかをチェックして、その範囲に入らない場合はすべてエラーとする設計にすれば、より安全なアプリケーションになります。
２．１ Webアプリケーションとファイアウォール
通常、Webサーバはファイアウォールの背後に置かれるため、インターネットからの攻撃はすべてファイアウォールが防いでくれると考えてしまいがちです。しかし、Webアプリケーションの脆弱性を狙った不正アクセス攻撃は、一般的にはファイアウォールでは防ぐことはできません。ファイアウォールは、一般にプロトコルとIPアドレスを基準にして不正攻撃かどうかを判断するため、通常のWebアクセスと同じHTTPやHTTPSのプロトコルを使用して行われるこれらの攻撃を、ファイアウォールは区別することができないからです。
こうしてファイアウォールを通過した攻撃によって、Webサーバがクラッカー（不正侵入者）に支配されてしまうと、今度はWebサーバを起点にしてさらに内部のネットワークまで攻撃にさらされてしまいます。
また、Webアプリケーションの脆弱性はそのアプリケーションに固有のものですから、一般的に知られた攻撃手法を検知するセキュリティ監視のシステムなどでも見つけることが困難なものが少なくありません。
Webアプリケーションについては、ファイアウォールやセキュリティ監視のような一般的なネットワークセキュリティ対策とは別に、アプリケーション自身で対策を実施しなくてはなりません。
２．２ Webアプリケーションの代表的な脆弱性
「クロスサイトスクリプティング」
クロスサイトスクリプティングは、Webアプリケーションの代表的な脆弱性の一つです。Webサイトに入力フォームがあり、入力したデータがそのままWebページとして出力されるアプリケーションの場合、出力するときにHTMLタグなどを適切に除去しないとこの問題が発生します。
悪意のある侵入者（クラッカー）は、この脆弱性を利用して、自分のサイトにある不正なスクリプト（利用者のクライアントで実行されるプログラム）を、脆弱性のあるターゲットサイトのコンテンツに見せかけて、利用者のクライアントに送信することができます。この結果、ターゲットサイトを信頼している利用者のクライアントで不正なプログラムが実行されてしまったり、クライアントに格納されているCookieと呼ばれる情報が盗まれてしまうなどの被害が発生します。
この問題は、ターゲットサイトではなく、そのサイトを信頼して利用している利用者に被害が出るため、被害はより深刻なものとなります。
「不正パラメータ」
Webアプリケーションが動作するためには、さまざまなパラメータ（変数）を利用者とサーバ間で交換する必要があります。そのほとんどは通常利用者が意識しない部分でプログラム同士で交換しているものですが、インターネット通信の知識と一般的なネットワーク用のソフトウェアツールがあれば、これらのパラメータのほとんどを利用者が自由に書き換えることができます。
これらのパラメータの値についてのチェックが十分でないと、Webアプリケーションが設計上想定していない動作となり、場合によってはデータを破壊したり、サーバがダウンしてしまったりという被害につながります。
実際に問題を起こしやすい不正パラメータの例として、
- 存在するパラメータの値を削って空白にしてしまう
- パラメータ自身を削除してしまう
- 1000文字など、極端に長い値を指定する
- OSやアプリケーションにとって特別な意味を持つ記号（制御文字）を指定する
- はいが「１」、いいえが「２」など値が決まっているときに、それ以外の値を指定する
などが知られています。
２．３ Webアプリケーションのセキュリティ設計
これまで見てきたような脆弱性を発生させないためには、Webアプリケーションの設計時からそのセキュリティを十分に考慮する必要があります。例えば、以下のような点を考慮しなければ、安全なWebアプリケーションとはなりません。
- パラメータのチェックをクライアントに任せず、サーバ側でかならずチェックする。
- クロスサイトスクリプティングを防ぐために、ユーザ入力データから有害な文字を取り除く（サニタイジング）。
- URLでのパラメータ受け渡し（クエリストリング）による脆弱性が発生しないように考慮する。
- hiddenフィールドを過信しない。
- Webフォームの選択項目でも、選択値を必ずチェックする。
Webアプリケーション設計のためのガイドラインとして、下記の情報源が一般に利用されています。
また、富士通ではセキュリティエキスパートによるWebアプリケーションの設計支援も行っております。
２．４ Webアプリケーションのセキュリティ診断
十分配慮して設計されたWebアプリケーションであっても、開発時のミスや思わぬ見落としによって、予期できない脆弱性が残ってしまっている場合があります。Webアプリケーションが本当に安全かどうかについて、第三者によるチェックを受ければ、より安心してWebシステムを運用できます。
富士通では、Webアプリケーション診断サービスを実施しています。Webアプリケーションセキュリティ診断ツールとして定評のあるSANCTUM社のAppScan(TM)によるツール診断と、Webセキュリティに精通したセキュリティエキスパートによる診断を併せて実施することにより、高精度・高品質のセキュリティ診断をご提供します。
Webアプリケーションでセキュリティ事件が発生すると、サービスの停止やデータ破壊といった直接的な損害だけではなく、ネットワークビジネスで最も重要なネットワーク社会での信頼を一瞬にして失ってしまいます。お客様のWebサイトを安全に運用し、信頼性を維持するためにぜひ富士通のセキュリティサービスをご活用ください。
