Azure Web アプリケーション ファイアウォールとは
ここでは、Azure Web Application Firewall の基礎について学習します。 この概要は、Azure Web Application Firewall が、Contoso の全体的なネットワーク セキュリティ戦略に追加するのに役立つツールであるかどうかを評価するのに役立ちます。
Azure Web Application Firewall の概要
悪意のあるユーザーが自分の Web アプリに悪さをすることなどないと思うかもしれません。 しかし、新しい Web アプリをデプロイしてから数分以内にはもう、ボットや悪意のあるアクターによって弱点が探られていることが、テストによって示されています。 Web にアプリを置く場合は、脅威となるアクターがほとんどすぐにアプリの脆弱性を試すものと思ってください。 また、そのような追及はアプリの有効期間にわたって続けられると想定されます。
Web アプリに対して行われる悪意のあるテストでは、ほとんどの場合、1 つまたは複数の一般的な脆弱性があるかどうかがチェックされます。 見つかった場合、脅威となるアクターはそれらの脆弱性を悪用して次のような攻撃を仕掛けるおそれがあります。
- SQL インジェクション
- クロスサイト スクリプティング
- ローカルおよびリモート ファイル インクルージョン
- HTTP/HTTPS フラッディング
- 悪意のあるボット攻撃
Web アプリ開発サイクルの一般的なタスクには、最も一般的なセキュリティ ホールを閉じるためのコードの記述が含まれます。 セキュリティ コードを記述するには、時間、専門知識、テストが必要です。
Azure Web Application Firewall は、Azure でホストされる Web アプリの保護を一元化する Azure サービスです。 Web アプリは、Azure Web Application Firewall により、SQL インジェクションやクロスサイト スクリプティングなどのよくある攻撃から保護されます。
Azure Web Application Firewall は数分でデプロイできます。 セキュリティ コードを 1 行も記述することなく、Web アプリはすぐに既知の脅威から強力に保護されるようになります。
Azure Web Application Firewall の主な機能
Azure Web Application Firewall の評価に役立つよう、その重要な機能をいくつか次に示します。
マネージド ルール: 一般的な悪用の検出と防止のために Azure Web Application Firewall で使用されるルールは、Microsoft のセキュリティ チームによって作成、管理、更新されます。 ルールが変更された場合、またはルール セット (後の説明を参照) が変更された場合は、Microsoft により Azure Web Application Firewall が自動的かつシームレスに更新されます。
Note
Azure Web Application Firewall によって提供されるマネージド ルールを、ユーザーが変更または削除することはできません。 ただし、環境で特定のルールが問題になっている場合は (Web アプリへの正当なトラフィックがブロックされる場合など)、除外の作成またはルールやルール セットの無効化を行うことができます。 また、既定の動作を上書きするカスタム ルールを作成することもできます。
ボットルール: ボット ルールに従うと、適切なボットを識別し、不適切なボットから保護することができます。 Microsoft 脅威インテリジェンスに基づいて、不適切なボットが検出されます。
カスタム ルール: Azure Web Application Firewall によって提供されるマネージド ルールが Web アプリケーションの特定の脅威に対応していない場合は、カスタム ルールを作成できます。
モード: Azure Web Application Firewall は、2 つのモードのいずれかで動作できます。検出モードのときは、ルールに違反する要求のログへの記録のみが行われます。一方、防止モードのときは、ルールに違反する要求のログへの記録とブロックの両方が行われます。
除外リスト: 要求のチェックで特定の属性が無視されるように、Azure Web Application Firewall を構成できます。
ポリシー: 一連のマネージド ルール、カスタム ルール、除外、および Azure Web Application Firewall の他の設定を、Azure Web Application Firewall ポリシーと呼ばれる 1 つの要素に結合できます。 その後、そのポリシーを複数の Web アプリに適用して、管理とメンテナンスを簡単に行うことができます。
要求サイズの制限: 小さすぎる、または大きすぎる要求にフラグを設定するように、Azure Web Application Firewall を構成できます。
アラート: Azure Web Application Firewall は Azure Monitor と統合されています。 この統合により、WAF によって脅威が検出されたときに、ほぼリアルタイムでアラートを受け取ることができます。
Azure Web Application Firewall によって阻止される一般的な攻撃
次の表では、Azure Web Application Firewall による保護に役立つ、最も一般的な悪意のある脅威の種類について説明します。
| Threat | [説明] |
|---|---|
| クロスサイト スクリプティング | 脅威となるアクターは、Web アプリケーションを使用して、悪意のあるコードを別のユーザーの Web ブラウザーに送信します。 ブラウザーによってコードが実行されると、スクリプトでユーザーのセッション データ、Cookie、その他の機密情報にアクセスできるようになります。 |
| ローカル ファイル インクルージョン | 攻撃者は、サーバーによる include ステートメント (多くの場合は PHP スクリプト内) の処理での脆弱性を悪用します。 特別に構成されたテキストをスクリプトの include ステートメントに渡すと、攻撃者は、サーバー上にローカルに存在するファイルをインクルードすることができます。 その後、攻撃者は機密情報にアクセスし、サーバー コマンドを実行できるおそれがあります。 |
| PHP インジェクション | 攻撃者は、特別に構成されたテキストを挿入して、サーバーに PHP コマンドを実行させます。 これらのコマンドを使用して、攻撃者はローカルまたはリモートの PHP コードを実行できます。 その後、攻撃者は機密データにアクセスしたり、サーバーでコマンドを実行したりできる場合があります。 |
| プロトコル攻撃 | 攻撃者は、特別に構成されたテキストを HTTP/HTTPS 要求ヘッダーに挿入します。 ヘッダーに挿入された特定のテキストに応じて、攻撃者はサーバーを騙して機密データを表示させたり、コードを実行したりすることができます。 |
| リモート コマンド実行 | 攻撃者は、サーバーのオペレーティング システムに関連付けられているコマンドを、サーバーに実行させます。 たとえば、UNIX システムでは、攻撃者がサーバーに ls を実行させて、ディレクトリのリストを取得することがあります。 |
| リモート ファイル インクルージョン | ローカル ファイル インクルージョンと同じですが、攻撃者が、リモート ファイル (つまり、攻撃者によって制御されるリモート サーバー上のファイル) をスクリプトの include ステートメントに渡す、特別に構成されたテキストをサーバーに送信する点が異なります。 |
| セッション固定 | 攻撃者は、Web アプリの脆弱性を悪用して、有効なセッション ID を取得できるようにします。 攻撃者は、ユーザーを騙して、その ID で新しいセッションの認証を行わせます。 その後、攻撃者は、このユーザーによって検証されたセッションをハイジャックします。 |
| SQL インジェクション | 攻撃者は、Web フォーム フィールドに特別に構成されたテキストを挿入 ("インジェクト") して、サーバーに SQL コマンドを実行させます。 これらのコマンドを使用すると、攻撃者は、機密データにアクセスしたり、データを挿入、更新、削除したり、SQL 操作を実行したりすることができます。 |
前の表で示されているすべての悪用は、サーバーが受信した入力を信頼している場合にのみ可能です。 これらの悪用をチェックして除去するコードを記述するのは困難で、時間がかかります。 前の表で示したのは、Web アプリに降りかかるおそれがある悪用のほんの一部です。 Azure Web Application Firewall は、これらの攻撃以外にも多くのものを防ぐように設計されています。
入力のサニタイズ
最新の Web アプリが直面する脅威は、多様で高度なものです。 ただし、ほとんどの場合、悪用が可能になるのは、Web アプリが受信した入力を暗黙的に信頼するためです。
たとえば、Web アプリの承認されたユーザーがユーザーのアカウントにサインインできる Web フォームを考えてみます。 そのフォームは、3 つの要素だけで構成されます。
- ユーザー名テキスト ボックス
- パスワード テキスト ボックス
- サインイン ボタン
承認されたユーザーがフォームに入力してサインインを選択すると、Web アプリのスクリプトによってユーザー名とパスワードが変数に格納されます。 それらの変数は、それぞれ userName および userPassword という名前であるものとします。 その後、スクリプトにより次のステートメントが実行されます。
sql = "SELECT * FROM users WHERE username='" + userName + "' AND password='" + userPassword + "'"
たとえば、ユーザー名が support でパスワードが 1234ABCD の場合、sql 変数の値は次のようになります。
SELECT * FROM users WHERE username='support' AND password='1234ABCD'
Web アプリによりこの SQL ステートメントが実行されます。 クエリからレコードが返された場合、Web アプリはユーザーをサインインさせます。
ここで、攻撃者がユーザー名フィールドに admin'-- を入力し、パスワード フィールドを空白のままにするとします。 この場合、結果の SQL ステートメントは次のようになります。
SELECT * FROM users WHERE username='admin'--' AND password=''
多くの SQL システムでは、二重ダッシュ (--) はコメントの開始を意味します。 -- より後にあるすべてのものは無視されるため、前のステートメントは次のコードと同等です。
SELECT * FROM users WHERE username='admin'
admin という名前のユーザーがいるとすると、このコマンドにより攻撃者は管理者ユーザーとしてサインインできます。これは重大な侵害です。
前の例は、"SQL インジェクション" と呼ばれる悪用の例です。 攻撃者は、すべての入力を信頼する Web アプリで、SQL インジェクションなどの悪用を利用できます。
Azure Web Application Firewall により、Web アプリとそのユーザーによる入力との間に "信頼しない" というバリアが作成されます。 Azure Web Application Firewall により、すべての入力は潜在的に悪意があるものと想定され、その入力が "サニタイズ" されます。
入力のサニタイズの意味は、コンテキストによって異なります。 たとえば、入力のサニタイズは、SQL のコメント インジケーターのような、明らかに危険なテキスト要素の削除を意味する場合があります。 しかし、サニタイズが行われると、結果は、Web アプリまたはそのバックエンド データに害を及ぼすことのない入力になります。