WAF はどのようにして脆弱性を軽減するのでしょうか?
近日公開予定の「アプリケーション配信の現状 2018」レポートでは、Web アプリケーション ファイアウォール (WAF) の使用が長年にわたって着実に増加していることが報告されています。 これは良いことです。なぜなら、今日のアプリは顧客データや企業データへのゲートウェイであり、ネットワーク層でアクセスを制御する従来の方法では不十分だからです。 なぜなら、デジタルゴールドを採掘するために、ID やアプリケーション自体を標的とする悪意のある行為者が増えているからです。
では、WAF は庭の雑草のように次々と現れる脆弱性を具体的にどのように軽減するのでしょうか? WAF が Web 攻撃を検出して防止するために使用する主な方法は、リクエストの拒否/許可、検査と拒否、署名の 3 つです。
それぞれ詳しく見ていきましょう。
リクエストの拒否/許可
要求を拒否/許可する方法は、ネットワーク ファイアウォールで使用される従来のドアウェイ モデルと非常によく似ています。 リクエストは、利用可能な情報に基づいて拒否または許可されます。 その情報は、IP アドレスのように単純なものもあれば、OPTIONS や METHODS のように HTTP に特有の複雑なものもあるかもしれません。
- 拒否/許可リスト
悪意のある攻撃者が特定の IP アドレスまたは IP アドレスの範囲から来ていることがわかっている場合は、その攻撃者をブロックします。 アプリケーションが特定の IP アドレスまたは IP アドレスの範囲からのリクエストのみを受信することを許可されていることが分かっている場合は、それらのリクエストのみを許可します。 これは最も単純な保護方法であり、リクエストが送信される IP アドレス/範囲など、かなり静的な情報セットに依存します。
ネットワーク ファイアウォールを使用すればいいのではないかと考えている方もいるでしょう。 結局のところ、それが彼らの仕事なのです。 オンプレミスでは、うまく機能します。 しかし、パブリック クラウドで保護する必要があるアプリがある場合、これは選択肢ではない可能性があります。 また、2018 年のアプリケーション配信の現状に関する調査で、すでに 2 ～ 6 社の異なるクラウド プロバイダーに投資している 59% の回答者のうちの 1 人である場合、ネットワーク ファイアウォール ポリシーがプロバイダー間で同じであるとは期待できません。 複数のクラウドに同じルールを実装することは確かに可能ですが、WAF でルールを適用すると、複数の環境の同じ WAF で同じポリシーを使用できるようになります。 一貫性はセキュリティの成功と拡張の鍵となります。 - オプションの制限
HTTP は、一連のヘッダーを使用して、ユーザーが実行したいことをアプリ プラットフォーム (およびアプリ) に指示します。 たとえば、HTTP メソッドは、リソースの GET、PUT、POST、および DELETE に使用できます。 OPTIONS フィールドにも、WAF によって簡単に制御できる RFC 制限の値セットがあります。 Optionsbleed などの一部の脆弱性は、これらのフィールドを悪用します。 このような脆弱性を悪用する能力を排除するために、WAF を使用して、アプリケーションの適切な実行を許可するために必要な値のみに可能な値を制限できます。 場合によっては、WAF はデフォルトでこれらの値を制限します。 たとえば、BIG-IP ASM (F5 WAF) では、デフォルトでは HTTP OPTIONS メソッドがまったく許可されません。
署名
署名は、さまざまなセキュリティ ソリューションに共通するもう 1 つの保護方法です。 ウイルス対策サービスとマルウェア対策サービスは、ウイルスやマルウェアの証拠をすばやくスキャンしてフラグを立てることができるシグネチャに依存しています。 IPS/IDS も WAF と同様にこの方法に大きく依存しています。 署名には、ユーザー定義とベンダー管理の 2 種類があります。
- ベンダー管理
ベンダー管理署名は通常、ベンダーによって自動的に管理される「データベース」に保存されます。 これには、新しい脆弱性が一意のデジタル署名によって識別された場合にデータベースを更新することが含まれます。 WAF は、受信したリクエストをデータベースに対してスキャンし、データベース内の署名と一致するものを発見した場合はそれに応じて動作します。 署名は純粋なプレーンテキストの場合もありますが、多くの場合、リモート実行機能をトリガーしたり、アプリ プラットフォームを破壊してアクセスを提供したりサービスを拒否したりする悪意のあるコードを表すわかりにくい文字列の複雑な組み合わせです。 - ユーザー定義
ユーザー定義の署名を使用すると、オペレーターはデータベースに署名をすばやく追加できます。 この機能は、新しい脆弱性に対する迅速な対応 (多くの場合、ゼロデイ) を確保するとともに、ベンダー管理の署名がまだ発行されていない脆弱性を軽減するために重要です。
検査
最後に、リクエスト (および応答) を完全に制御できるように検査が組み込まれています。 リクエストを検査することで、WAF はリクエスト内の情報を既知の正常/不正な文字列や値と比較して、リクエストが悪意のあるものか正当なものかを判断することができます。 HTTP アプリケーション (今日のインターネット上のほとんどのアプリケーション) の場合、これは WAF が提供するべき最も重要な機能です。 WAF がプログラム可能な検査を提供していない場合は、その選択を再検討する必要があります。 HTTP はテキストベースで拡張可能であるため、リクエストを検査するために使用できるオプションとメソッドの包括的な「チェックボックス」リストを提供する方法は事実上ありません。 オプションが制限されている HTTP ヘッダーはほとんどなく、そこに何を詰め込めるか、何を詰め込めないかを制限するのは非常に困難です。 つまり、ヘッダーまたはペイロード自体に埋め込まれた悪意のあるコードを検出するために、検査が必要になることがよくあります。 検査を使用するには、既知のヘッダーとペイロードの 2 つの方法があります。
- 既知のヘッダー
すべての HTTP リクエストには、明確に定義された一連のヘッダーが付属しています。 ホスト、ユーザーエージェント、コンテンツタイプなどは、ほぼどこにでもあります。 それぞれは単なるテキストの文字列であり、組み合わせが非常に多岐にわたるため、値を許可リストに登録するのは困難であり、代わりに悪意のある値がないかどうかを個別にスキャンする必要があります。 一般的に言えば、WAF は HTTP ヘッダーを非常に迅速に解析し、検査を可能にします。 これらはすべてのリクエストの先頭にあり、アプリ プラットフォームに対するさまざまな攻撃を実行するために使用されることが知られています。 アパッチキラー、 オプションブリード、 そして アパッチストラッツ よく知られている脆弱性の 1 つです。 - ペイロード検査
ペイロード検査は、その名の通り、最初のバイトから最後のバイトまでペイロード全体を検査し、脆弱性を悪用しようとする試みを示す英数字データの既知の組み合わせを探します。 ペイロード検査により、オペレーターはカスタム HTTP ヘッダーとリクエスト本文を調べて、悪意のあるアクティビティの特定の兆候を探すことができます。 これには、WAF が最初にリクエストの内容全体を保持する必要があります。 これが必要なのは、パケットが保持できるデータ量に限りがあり、悪意のあるデータが 2 つのパケットにまたがっている場合、パケット単位で検査するだけのサービスでは気付かれない可能性があるためです。 WAF はペイロード全体を検査することで、悪意のあるデータがどこで発生しても、それを探し出してターゲットに到達するのを防ぐことができます。
WAF は、脆弱性を軽減してアプリケーションを保護する以外にも多くの機能を備えています。 多くにはボット検出、レート制限、DDoS 防止などの機能も含まれています。 しかし、WAF の中心的な目的は、脆弱性を軽減してアプリケーションを保護することです。 SQLi、XSS、CSRF がよく言及されますが、これらは現時点ではほとんど「古い」ものです。 悪意のある行為者は、明らかなアプリの脆弱性を超えて、プラットフォームを標的にし始めました。プラットフォームには、攻撃の標的となる被害者のプールがはるかに大きいためです。 プラットフォームの脆弱性（HTTP とそのフレームワークの脆弱性）は、エンタープライズ クラスの WAF によって提供される保護の恩恵を受ける侵害の原因として増加しています。
WAF は、従来の拒否/許可および署名ベースのスキャンと、完全なリクエスト (および応答) を検査する機能を採用することで、自社とその顧客を安全に保つために今日のビジネスに必要な保護を提供します。