Webアプリを脅威から守る対策の実践

　Webアプリケーションのセキュリティ対策といっても、読者の皆さんすべてがITマネジャーやセキュリティ担当者などのアプリケーション開発者ではないだろう。そこでここでは、アプリケーション開発者向けのセキュアプログラミングの具体的な手法については触れず、システムインテグレーターから納入されたシステムを受け入れ検証したり、既に運用中のシステムに欠陥がないかどうかを確認するための「脆弱性検査」と、多層防御の観点からWebアプリを防御するために導入する「WAF（Web Application Firewall）」の2つを中心に説明する。

2つの脆弱性検査

　まず脆弱性検査について説明する。一昔前は脆弱性検査といえば、サーバレベル、実際にはOSやミドルウェアの検査を目的に、ネットワーク越しに検査対象のサーバに対して疑似侵入攻撃を実施していたが、ここでいう脆弱性検査はWebアプリに対する脆弱性検査である（図4）。

図4●サーバ検査とWebアプリ検査の対象の違い

　検査の手法は、大きく2種類に分かれる。1つはWebアプリのソースコードをチェックする方法、もう1つは動作しているWebアプリに対して、Webブラウザや専用ツールなどにより、疑似攻撃をする形で検査する方法（ブラックボックス検査）である。

　それぞれの検査手法ともに、表1にあるような無償ツールや製品が販売されているので、興味があれば利用してみるとよいだろう。これはあくまで筆者の私見だが、ソースコード検査はWebアプリ全体を対象にして検査を実施できるが、検出できる脆弱性が限られているのが課題だろう。また、検査の精度を向上させるにはそれなりのプログラミングとセキュリティに関する知識が要求されるのも、一般企業にはつらいところだ。一方、疑似攻撃による検査は、プログラミング知識がなくてもツールを利用することで誤検出を減らすことが可能だが、ソースコード検査に比べてコストが高くつくはずだ。

　ツールで行う検査は、人間が実施する場合に比べて低コストだが、半面、検査の質が低く、ツールの特性上単一のツールでは検出できない脆弱性もあるので、ツールの特性を理解した上で利用していただきたい。具体的には検査で使うツールが、要件で求められているセキュリティ対策が実施されていることを確認するツールなのか、見つけたい脆弱性を検出できるツールなのか、といったことを検討した上で利用しないと、後で「時間と費用の無駄だった」ということになりかねないので気を付けてほしい。

　では、セキュリティベンダーの検査サービスはどうか。まず、市販の検査ツールを使ってスキャンするだけのサービスは、あまり検査品質が高いとは言いにくい。理由は先ほど検査ツールのところで述べた通りで、現時点では万能のツールは存在しないからだ。やはりツールに加えて、相応の技術者が対象のWebアプリの特性を考慮しながら、経験と勘を駆使して検査をしているようなところは、検査の品質が高い。ただし、それと同時に料金も高額になってしまう。

※手前みそであるが、ラックのWebアプリ診断サービスは、自社開発のツールに加えて、検査スペシャリストによる手動診断を実施している。

　Webアプリの欠陥が見つかるのなら早い方がよいと考えるのに異論の余地はないだろう。読者の関係するシステムがまだリリース前なら、ぜひソースコード検査の実施を推奨したい。

　ソースコード検査では、アプリケーションの設計に依存するセッション管理の不備やエラー処理の不備、CSRF（クロスサイトリクエストフォージェリ　※注2）などを見つけるのは不得手だが、XSS（クロスサイトスクリプティング　※注3）やSQLインジェクションなどの入出力処理に関する脆弱性を検出することは得意である。これらの脆弱性はプログラマーによって作り込まれることが多く、確認すべき個所も膨大だ。そのため、ツールによって早い時期に、全プログラムを対象に検査を行うことで、機能面の不具合と同じように修正することがポイントとなる。脆弱性を速やかになくすことは、リリース後に対応することに比べて、手戻りコストを大幅に削減できるだろう。いずれにしても早期に、ソースコード検査とブラックボックス検査を組み合わせて実施することで、最小のコストでのセキュアなWebアプリ構築に役立ててほしい。

※注2　Webサイト間を横断して悪意のある不正スクリプトを埋め込み、サイトを閲覧したユーザーとサーバ双方に被害を与える攻撃手法。

※注3　WebサイトにHTTPリクエストや不正スクリプトを仕込むことによって、閲覧したユーザーに別のサイト上で意図しない操作を実行させる攻撃手法。

Webアプリの防御に特化したWAF

　次にWAFについて説明しよう。まず、ファイアウォール（以下、FW）、IDS／IPS、WAFの簡単な役割、対象レイヤーの違いを説明しておく（図5）。FWは、送信元とあて先のIPアドレス（レンジ指定も可）やプロトコル別に通信を許可／遮断させることができる。通常は、各サーバが提供しているサービスのみに接続できるよう設定されている。IDS／IPSは、FWが許可している通信の範囲で各デーモンやミドルウェアなどを対象とした攻撃を検知、遮断することができる。WAFは、プロトコル上はHTTP、HTTPSに特化しており、ミドルウェアに対する攻撃ではなく、Webアプリそのものに対する攻撃を検知、遮断することができる。

図5●WAF、FW、IDS／IPSの違い

　公開されているWebシステムの構成の中には大抵、通常のFW、IDSまたはIPSが既に含まれているはずである。それなのに、さらにWAFなるものが必要なのだろうか？　常に「Yes」というわけではないが、WebアプリはFWでは守れないし、IDS／IPSを普通に導入しているだけでも守れない。自社のWebアプリにはセキュリティホールはないと考えるユーザーもいるが、残念ながら人間のやることにミスは付きものである。業界内における自社の地位、Webアプリが扱う情報の重要性などを考慮したときに万が一にも止まっては困るということであれば、“もしも”に備えておくことを検討する必要はあるだろう。

　WAFと聞いて読者が想像するのはネットワーク型だと思うが、実はホスト型もある（表2）。一般的にホスト型の方が安く、導入しやすいのだが、これまで無事に動作していた環境に新たなプログラムをインストールするのはちゅうちょしてしまうものだ。実際、対象サーバのリソース消費、パフォーマンス低下、WAFプログラムの異常終了などのリスクは高まる。しかし、テスト環境における各種のテストを行い、通常の障害対応のようにシステム運用を整備しておけば、それらのリスクと向き合うことができるだろう。

　どちらのタイプのWAFを導入するにしても、対象のWebアプリの特性を考慮して検知、遮断のルールを設定することには変わりない。製品によっては学習モードを装備し、ホワイトリストを自動作成してくれるものもあるが、一般的にはパラメータのレングスの上限を設定し、しきい値を超えた場合を不正アクセスと見なす設定から始め、例外のページ（Webアプリ）のみ個々に適切な値をセットし、運用しながらそれらをチューニングしていくのだ。

　余談だが、WAFはアプリケーション層専用の機器だが、価格的にはまだまだ高い。もし皆さんの関係するサイトにIPSが既に導入されているのであれば、機器の種類、運用体制、トラフィック状況など多少制限はあるが、われわれを含む一部のセキュリティベンダーが提供している監視サービスに切り替えることで大きな追加投資をせずにIPSをWAFとして活用することもできる。

　Webアプリ対策の神髄は、セキュアなWebアプリを作ることである。しかし、これは思っているほど簡単なことではない。なぜなら、ほとんどの部分を人間が作り、しかもミスが1つも許されないからである。現実的な手段としては、欠陥がどこかにあるという前提で、定期的に欠陥を検出するための対策や、それらの欠陥を攻撃されたときにいち早く検知して被害を小さくするための歯止め策、あるいは遮断する対策などを、バランスよく実施することである。