このエントリは何年も前（日付を見たら2008年８月）に書きかけで放置していたエントリです。最近書いた、セッションアダプション脆弱性をPHPのモジュールレベルで修正するパッチについての議論の参考になると思うので公開します。私は補助的な意味合いを持つ追加のセキュリティ対策は無意味であるとは全く考えていません。対策の限界を知って、有効に利用する。それで良いのでは無いでしょうか？以下、書きかけで未公開だったエントリです。
関連エントリ： セッションフィクセイションはアダプション脆弱性修正で防御可能 （特にコメント欄）
WAFは有用なセキュリティ対策です。これに異論は無いでしょう。ゼロデイ対策にはWAFは非常に有効であり、可能であれば導入すべきだ、とセミナーでも繰り返し説明しています。しかし、WAFは万能ではありません。導入すれば安全性が簡単かつ飛躍的に向上するシステムでもありません。説明を省略しているので説明不足な部分もありますが、疑問がある場合はコメントをください。
無駄が多いホワイトリスト型のチェックルール
ホワイトリスト型のチェックルールをWAFに実装する為には、アプリケーションが入力データがどの様に利用されるのか、ツール設計者が理解しなければなりません。少なくとも、どの様なデータ形式のデータを受け入れるのかルールを知らなければなりません。 最近のWebアプリはアジャイルスタイルの開発が行われている事が多く、実際にデータがどの様に利用されているのか知るにはコードに埋め込まれたドキュメントを参照する事が多いです。コード自体を参照しなければならない事も多くあるでしょう。コードを参照するのであれば、コード監査を行う方が合理的です。安全性に配慮したコードなら、全ての入力値は最小権限の原則に従い、厳格にチェックされているはずです。WAFルールの設計者は基本的にコードに書かれたバリデーションルールを書き直す作業を行うに過ぎません。コード監査であれば、バリデーションルールが妥当であるかもチェック対象になるでしょうが、WAFルールの設計であればコードの中身まで踏み込んでチェックは行わないでしょう。コードの中身までチェックするならWAFルールの設計でなく、コードの監査+WAFルールの設計になってしまします。 ホワイトリスト型のWAFルールは運用管理の手間も増加させます。WAFルールの作成はアプリが完成してから行うのが最も効率が良いので、ルール作成は完成後かテストフェーズから行う事になるでしょう。テストフェーズでWAFルールを作りながらテストするとアプリの問題なのかWAFルールの問題なのか切り分けの手間が発生します。完成後にWAFルールを作るなら同じようなテストをまた繰り返し行う事になります。 厳格なバリデーションを行うWAFルールを書いた場合、ちょっとしたアプリの修正でもWAFルールの修正が必要になります。コードの修正、コード修正の確認、WAFルールの修正、WAFルール修正の確認を修正・変更の度に行わなければなりません。
パフォーマンスへの影響
あまり多くのバリデーションルールを定義し利用すると、WAFのパフォーマンスは簡単に低下します。ホワイトリスト型のWAFルールを作るとルールの数は飛躍的に増加します。ロードバランサで負荷分散も加能ですが、コストの増となってしまいます。商用のWAFは数百万ほどですが、比較的大手のサイトでも何台も気前よく買ってメンテナンスできる価格ではありません。 複雑なバリデーション処理は安くなったサーバ機でアプリ機能の一部として処理した方が効果的です。
入力に対するセキュリティ対策
WAFは入力に対するセキュリティ対策です。不正なiframeの挿入された場合等に出力を防ぐ事も可能ですが、WAFは基本的に入力に対するセキュリティ対策です。 しかし、セキュリティ対策は入力と出力の両方に適切な対策が必要です。一つの入力が複数の目的に利用された場合、WAFでは対処できない場合がります。典型的な例は、自由に入力可能なテキスト入力がブラウザとRDBMSの両方に出力されている場合です。 ブラウザに出力する場合、HTML/JavaScriptインジェクションを防ぐためのチェックを追加しなければなりません。 RDBMSに出力する場合、SQLインジェクションを防ぐためのチェックを追加しなければなりません。 両方を満たすチェックルールは書けません。これは入力時のセキュリティ対策と出力時のセキュリティ対策が異なる事が原因です。いくら入力時に可能な限り厳格なバリデーションを行っても、アプリが出力の際にセキュリティ対策を怠っていると保護できません。
アプリに問題があったら、やはりアプリを修正しなければならない
WAFベンダーで「アプリの脆弱性修正は必要ありません」と言っていても「アプリの脆弱は”ずっと”修正する必要はありません」などと言うベンダーは無いはずです。あれば是非教えていただきたいです。 アプリの問題は最終的にアプリで解決しなければなりません。
コストメリットの問題
WAFは物なので細かい事をあまり気にしなければ購入して初期設定を行えば直ぐに利用できます。細かい事を気にしなければ、コード監査を行い、必要な修正を行い、テストするよりかなり安く済むかも知れません。 しかし、細かい事を気にせず導入したWAFがどのくらい安全性向上に役立つでしょうか? システムセキュリティに於ける攻撃者と防御者の戦いは攻撃者が圧倒的に有利です。攻撃する側はたった一つ攻撃パスを見つけるだけで十分です。それに対して防御する側は全てを防御しなければなりません。 攻撃する側は細かい事など気にしなくても良いですが、セキュリティを守る側は些細な事まで気にしなければなりません。些細な事をWAFでチェックするのは既に記述した通り、無理もありますしコストも多く必要になります。
WAFの利用は最小限度。最初からアプリでチェックした方がコストパフォーマンスが良い
既に完成したアプリケーションなら、ケースバイケースですが、これから作るアプリケーションなら最初からWAFでチェック可能なセキュリティ機能をアプリに付けた方が効率的です。コード監査によってルールの監査も可能ですし、テストも運用も楽になります。 必要最小限のWAF導入とWAFに頼ったセキュリティ対策の導入、どちらがコストパフォーマンスよく、求められるセキュリティレベルを達成できるのかシュミレーションすると良いと思います。 WAFの導入は安くありません。WAFルールの作成、チェック、運用、メンテナンス。WAFハードウェアの購入・保守のコスト全てを考え計算すると、どちらが効率的であるか分かります。
WAFの利用方法
WAFはゼロデイ対策とフェイルセーフ対策として利用すべきです。アプリケーションが直ぐには対応できない脆弱性が発見された場合に、恒久的な対策を実施するまでの一時的な回避策としての利用とアプリケーションに万が一単純な脆弱性があった場合でも攻撃を検出できるようにします。 橋の橋脚に例えるなら、WAFは補強のような物です。普段は必要無くても万が一の場合に備えるシステムとして利用すべきです。
Leave a Comment