NetScaler Web App Firewallの概要

最終公開日 : Sep 25, 2026
NetScaler Web App Firewallは、機密のビジネス情報や顧客情報にアクセスするWebサイトへのセキュリティ侵害、データ損失、および不正な変更を防止します。そのために、リクエストとレスポンスの両方をフィルタリングし、悪意のあるアクティビティの証拠がないか調べ、そのようなアクティビティを示すリクエストをブロックします。サイトは、一般的なタイプの攻撃だけでなく、まだ未知の新しい攻撃からも保護されています。Web App Firewall は、Web サーバーと Web サイトを不正アクセスから保護するだけでなく、レガシー CGI コードまたはスクリプト、Web フレームワーク、Web サーバーソフトウェア、およびその他の基盤となるオペレーティングシステムの脆弱性からも保護します。
NetScaler Web App Firewallは、スタンドアロンアプライアンスとして、またはNetScaler ADC仮想アプライアンス（VPX）の機能として利用できます。Web App Firewallのドキュメントでは、NetScaler ADCという用語は、そのプラットフォームが専用のファイアウォールアプライアンス、他の機能も構成されているNetScaler ADC、またはNetScaler ADC VPXであるかどうかに関係なく、Web App Firewallが実行されているプラットフォームを指します。
Web App Firewall を使用するには、保護されている Web サイトに設定したルールに違反する接続をブロックするセキュリティ構成を少なくとも 1 つ作成する必要があります。作成するセキュリティ設定の数は、Web サイトの複雑さによって異なります。場合によっては、1 つの構成で十分な場合もあります。また、特にインタラクティブなWebサイト、データベースサーバーにアクセスするWebサイト、ショッピングカートのあるオンラインストアなどのケースでは、特定の種類の攻撃に対して脆弱ではないコンテンツに多大な労力を費やすことなく、機密データを最大限に保護するために、いくつかの異なる構成が必要になる場合があります。多くの場合、すべてのセキュリティ設定に影響するグローバル設定のデフォルトはそのままにしておくことができます。ただし、構成の他の部分と競合する場合や、カスタマイズしたい場合は、グローバル設定を変更できます。
Related information

Web アプリケーションセキュリティ

Web アプリケーションセキュリティは、HTTP および HTTPS プロトコルを使用して通信するコンピューターとプログラムのネットワークセキュリティです。これは、セキュリティ上の欠陥や弱点が多く存在する幅広い分野です。サーバーとクライアントの両方のオペレーティングシステムにはセキュリティ上の問題があり、攻撃に対して脆弱です。CGI、Java、JavaScript、PERL、PHP などの Web サーバーソフトウェアや Web サイト対応テクノロジーには、根本的な脆弱性があります。Web 対応アプリケーションと通信するブラウザやその他のクライアントアプリケーションにも脆弱性があります。訪問者とのやりとりを可能にするサイトを含め、最も単純な HTML 以外のテクノロジーを使用している Web サイトには、多くの場合、独自の脆弱性があります。
以前は、セキュリティ違反は単なる煩わしさであることが多かったが、今日ではそうなることはめったにない。たとえば、ハッカーがWebサーバーにアクセスし、Webサイトに不正な変更（改ざん）を加える（改ざん）する攻撃が一般的でした。通常、他のハッカーに自分のスキルを見せたり、対象となる個人や企業を当惑させたりする以外に動機のないハッカーによって立ち上げられました。しかし、現在のセキュリティ侵害のほとんどは、金銭への欲求によって動機付けられています。大多数は、機密性が高く潜在的に貴重な個人情報を取得すること、またはウェブサイトまたはウェブサーバーへの不正アクセスや制御を得ることのいずれかまたは両方を達成しようとします。
特定の形態のウェブ攻撃は、個人情報の取得に重点を置いています。これらの攻撃は、攻撃者が完全に制御できないほど安全な Web サイトに対しても発生することがよくあります。攻撃者が Web サイトから取得できる情報には、顧客の名前、住所、電話番号、社会保障番号、クレジットカード番号、医療記録、およびその他の個人情報が含まれます。攻撃者はこの情報を利用したり、他の人に売ったりすることができます。このような攻撃によって得られる情報の多くは法律によって保護されており、そのすべては慣習と期待によって保護されています。この種の違反は、個人情報が漏洩した顧客に重大な結果をもたらす可能性があります。せいぜい、これらの顧客は、他人がクレジットカードを悪用したり、自分の名前で無許可のクレジットカードを開設したり、個人情報をあからさまに流用したり（個人情報の盗難）したりしないように警戒しなければなりません。最悪の場合、顧客は信用格付けの低下に直面したり、自分が関与していない犯罪行為のせいにされたりする可能性があります。
*他のWeb攻撃は、WebサイトまたはWebサイトが動作するサーバー、あるいはその両方を制御（または侵害）することを目的としています。*ウェブサイトやサーバーの制御権を獲得したハッカーは、それを使って不正なコンテンツをホストしたり、別のウェブサーバーでホストされているコンテンツのプロキシとして機能したり、SMTPサービスを提供して迷惑な大量のメールを送信したり、侵害された他のウェブサーバーでのそのような活動をサポートするためのDNSサービスを提供したりする可能性があります。侵害されたウェブサーバーでホストされているほとんどのウェブサイトは、疑わしいビジネスやあからさまな詐欺行為を助長しています。たとえば、ほとんどのフィッシングWebサイトや児童搾取Webサイトは、侵害されたWebサーバーでホストされています。
ウェブサイトやウェブサービスをこれらの攻撃から守るには、識別可能な特徴を持つ既知の攻撃をブロックすることと、未知の攻撃を防ぐことの両方が可能な多層防御が必要です。未知の攻撃は、ウェブサイトやウェブサービスへの通常のトラフィックとは異なっているために検出されることがよくあります。
セキュリティチェックの詳細については、「 セキュリティチェックの概要」を参照してください。

既知のウェブ攻撃

Webサイトの第一の防衛線は、存在することが知られており、Webセキュリティの専門家によって観察および分析された多数の攻撃からの保護です。HTML ベースの Web サイトに対する一般的な攻撃には、次の種類があります。
  • **バッファオーバーフロー攻撃。**長い URL、長い Cookie、または長い情報を Web サーバーに送信すると、システムがハングアップしたり、クラッシュしたり、基盤となるオペレーティングシステムに不正にアクセスしたりします。バッファオーバーフロー攻撃は、不正な情報にアクセスしたり、Web サーバーを危険にさらしたり、あるいはその両方を行うために利用される可能性があります。
  • **クッキーセキュリティ攻撃。**改ざんされたCookie をウェブサーバーに送信すること。通常、偽造された認証情報を使用して不正なコンテンツにアクセスすることを期待します。
  • **強制的なブラウジング。**ホームページ上のハイパーリンクの付いた URL や Web サイト上のその他の一般的な開始 URL に移動せずに、Web サイトの URL に直接アクセスする。強制ブラウジングの個々の事例は、ユーザーが Web サイトのページをブックマークしたにもかかわらず、存在しないコンテンツやユーザーが直接アクセスしてはならないコンテンツに繰り返しアクセスしようとすると、Web サイトのセキュリティに対する攻撃と見なされることがよくあります。強制ブラウジングは通常、権限のない情報にアクセスするために使用されますが、バッファオーバーフロー攻撃と組み合わせてサーバーを危険にさらすこともあります。
  • **Web フォームのセキュリティ攻撃。**不適切なコンテンツを Web フォームで Web サイトに送信すること。不適切なコンテンツには、修正された隠しフィールド、HTML、または英数字データ専用フィールドのコード、短い文字列のみを入力するフィールド内の長すぎる文字列、整数のみを受け入れるフィールドの英数字文字列、Web サイトがその Web フォームで受け取ることを想定していないさまざまなデータなどがあります。Web フォームセキュリティ攻撃は、通常はバッファオーバーフロー攻撃と組み合わせて、Web サイトから不正な情報を取得したり、Web サイトを完全に侵害したりするために利用されます。
特筆すべきは、Web フォームセキュリティに対する 2 種類の特殊な攻撃です。
  • **SQL インジェクション攻撃。**SQL データベースに 1 つまたは複数のコマンドを実行させることを目的として、アクティブな SQL コマンドを Web フォームで、または URL の一部として送信すること。SQL インジェクション攻撃は通常、不正な情報を取得するために使用されます。
  • **クロスサイトスクリプティング攻撃。**Web ページの URL またはスクリプトを使用して同一生成元ポリシーに違反すること。同一生成元ポリシーでは、スクリプトが別の Web サイトのプロパティを取得したり、別の Web サイトのコンテンツを変更したりすることを禁じています。スクリプトは Web サイトの情報を取得したり、ファイルを変更したりできるため、スクリプトが別の Web サイトのコンテンツにアクセスできるようにすると、攻撃者は不正な情報を取得したり、Web サーバーを侵害したり、あるいはその両方を行ったりする可能性があります。
XML ベースの Web サービスに対する攻撃は、通常、Web サービスに不適切なコンテンツを送信しようとする試み、もう 1 つは Web サービスのセキュリティを侵害しようとする攻撃の 2 つのカテゴリのうち少なくとも 1 つに分類されます。XML ベースの Web サービスに対する一般的な攻撃には、次の種類があります。
  • **悪意のあるコードまたはオブジェクト。**機密情報を直接取得したり、攻撃者に Web サービスや基盤となるサーバーを制御させたりする可能性のあるコードまたはオブジェクトを含む XML リクエスト。
  • **XML リクエストの形式が正しくありません。**W3C XML 仕様に準拠していないため、安全ではない Web サービスのセキュリティを侵害する可能性のある XML リクエスト
  • **サービス拒否 (DoS) 攻撃。**ターゲット Web サービスに負荷をかけ、正規ユーザーの Web サービスへのアクセスを拒否する目的で、大量に繰り返し送信される XML 要求。
XML Web サービスと Web 2.0 サイトは、標準的な XML ベースの攻撃に加えて、以下に説明するように SQL インジェクションやクロスサイトスクリプティング攻撃にも脆弱です。
  • **SQL インジェクション攻撃。**SQL データベースにそのコマンドを実行させる目的で、XML ベースのリクエストでアクティブな SQL コマンドまたはコマンドを送信すること。HTML SQL インジェクション攻撃と同様に、XML SQL インジェクション攻撃は通常、不正な情報を取得するために使用されます。
  • **クロスサイトスクリプティング攻撃。**XML ベースのアプリケーションに含まれるスクリプトを使用して、同一生成元ポリシーに違反すること。同一生成元ポリシーでは、どのスクリプトも別のアプリケーションのプロパティを取得したり、コンテンツを変更したりすることはできません。スクリプトは XML アプリケーションを使用して情報を取得したりファイルを変更したりできるため、別のアプリケーションのコンテンツへのスクリプトアクセスを許可すると、攻撃者は不正な情報を取得したり、アプリケーションを危険にさらしたり、あるいはその両方を行ったりする可能性があります。
既知の Web 攻撃は、通常、Web サイトのトラフィックを特定の特性（シグネチャ）でフィルタリングすることで阻止できます。これらの特徴は、特定の攻撃では必ず出現しますが、正規のトラフィックには絶対に出てはなりません。このアプローチには、必要なリソースが比較的少なく、誤検出のリスクも比較的少ないという利点があります。そのため、ウェブサイトやウェブサービスへの攻撃に対抗し、基本的な署名保護を設定する上で貴重なツールです。

未知のウェブ攻撃

ウェブサイトやアプリケーションに対する最大の脅威は、既知の攻撃ではなく、未知の攻撃によるものです。未知の攻撃のほとんどは 2 つのカテゴリのいずれかに分類されます。1 つは、セキュリティ会社がまだ効果的な防御策を開発していない新規攻撃です（ゼロデイ攻撃）。もう 1 つは、多くの Web サイトや Web サービスではなく、特定の Web サイトまたは Web サービスを狙った攻撃（スピア攻撃）です。これらの攻撃は、既知の攻撃と同様に、機密性の高い個人情報を取得し、ウェブサイトやウェブサービスを危険にさらしてさらなる攻撃に使用できるようにすること、あるいはその両方を目的としています。
ゼロデイ攻撃はすべてのユーザーにとって大きな脅威です。これらの攻撃は通常、既知の攻撃と同じタイプです。ゼロデイ攻撃には、SQL の注入、クロスサイトスクリプト、クロスサイトリクエストフォージェリ、または既知の攻撃に類似した別の種類の攻撃が含まれることがよくあります。通常、対象となるソフトウェア、Webサイト、またはWebサービスの開発者が気付いていない、または発見したことのない脆弱性を標的にします。そのため、セキュリティ企業はこれらの攻撃に対する防御策を開発しておらず、たとえ開発したとしても、ユーザーはこれらの攻撃からの保護に必要なパッチを入手してインストールしたり、回避策を実行したりしていません。ゼロデイ攻撃が発見されてから防御が可能になるまでの時間（脆弱性ウィンドウ）は短くなっていますが、攻撃者は依然として、多くのウェブサイトやウェブサービスが攻撃に対する特定の保護策を欠いているため、何時間も、あるいは何日もかかる可能性があります。
スピア攻撃は大きな脅威ですが、特定のユーザーグループにとっては脅威です。スピア攻撃の一般的なタイプであるスピアフィッシングは、特定の銀行や金融機関の顧客、または（あまり一般的ではありませんが）特定の企業や組織の従業員を標的にします。他のフィッシングは、その銀行や金融機関の実際の通信に精通しているユーザーなら認識できる、大雑把に書かれた偽造品であることが多いですが、スピアフィッシングは文字どおりで説得力があります。それらには、見知らぬ人が知っていたり、入手できたりしてはならない個人固有の情報が含まれている場合があります。したがって、スピアフィッシング詐欺師は、要求された情報を提供するように標的を説得することができます。この情報を使用して、アカウントを略奪したり、他のソースから不正に入手した金銭を処理したり、さらに機密性の高い他の情報にアクセスしたりすることができます。
どちらのタイプの攻撃にも、通常は検出できる特定の特性があります。ただし、標準のシグネチャのように特定の特性を探す静的パターンを使用することはできません。この種の攻撃を検出するには、ヒューリスティックフィルタリングやポジティブセキュリティモデルシステムなど、より高度でリソースを大量に消費するアプローチが必要です。ヒューリスティックフィルタリングは、特定のパターンではなく、行動のパターンを対象としています。ポジティブセキュリティモデルシステムは、保護対象の Web サイトまたは Web サービスの通常の動作をモデル化し、その通常の使用モデルに当てはまらない接続をブロックします。URL ベースと Web フォームベースのセキュリティチェックでは、Web サイトの通常の使用状況をプロファイリングし、ヒューリスティックとポジティブセキュリティの両方を使用して異常なトラフィックや予期しないトラフィックをブロックして、ユーザーの Web サイトとのインタラクションを制御します。ヒューリスティックなセキュリティとポジティブなセキュリティの両方を適切に設計して導入すれば、シグネチャが見逃すほとんどの攻撃をキャッチできます。ただし、これらはシグニチャよりもかなり多くのリソースを必要とするため、誤検出を防ぐにはある程度の時間をかけて適切に設定する必要があります。そのため、これらは主要な防御線としてではなく、シグネチャのバックアップやその他のリソースをあまり消費しないアプローチとして使用されます。
シグネチャに加えてこれらの高度な保護を設定することで、ハイブリッドセキュリティモデルを作成できます。これにより、Web App Firewall は既知の攻撃と未知の攻撃の両方に対する包括的な保護を提供できます。

NetScaler Web App Firewall 仕組み

Web App Firewall をインストールすると、ポリシー、プロファイル、および署名オブジェクトで構成される初期セキュリティ設定を作成します。ポリシーは、フィルタリングするトラフィックを識別するルールであり、プロファイルは、トラフィックがフィルタリングされるときに許可またはブロックする動作のパターンとタイプを識別します。シグネチャと呼ばれる最も単純なパターンは、プロファイル内ではなく、プロファイルに関連付けられたシグネチャオブジェクトで指定されます。
シグネチャは、既知の攻撃タイプと一致する文字列またはパターンです。Web App Firewall には 7 つのカテゴリに 1000 を超えるシグネチャが含まれており、それぞれが特定の種類のウェブサーバーや Web コンテンツへの攻撃を目的としています。NetScalerは、新しい脅威が特定されると、新しいシグネチャでリストを更新します。設定時に、保護する必要のあるウェブサーバーとコンテンツに適した署名カテゴリを指定します。シグネチャは、処理のオーバーヘッドを低く抑えながら、基本的な保護を良好に行います。アプリケーションに特別な脆弱性がある場合、またはシグネチャが存在しない攻撃を検出した場合は、独自のシグネチャを追加できます。
より高度な保護はセキュリティチェックと呼ばれます。セキュリティチェックは、保護対象の Web サイトや Web サービスに対する攻撃や脅威となる可能性のある、特定のパターンや動作の種類について、リクエストをより厳密にアルゴリズムに基づいて検査することです。たとえば、セキュリティを侵害する可能性のある特定の種類の操作を実行しようとするリクエストや、社会保障番号やクレジットカード番号などの機密性の高い個人情報を含む応答を特定できます。構成時に、保護する必要のあるウェブサーバーとコンテンツに適したセキュリティチェックを指定します。セキュリティチェックは制限が厳しいです。それらの多くは、設定時に適切な例外 (緩和) を追加しないと、正当な要求や応答をブロックする可能性があります。アダプティブラーニング機能を使えば、ウェブサイトの通常の使用状況を観察して推奨例外を作成するので、必要な例外を特定するのは難しくありません。
Web App Firewall は、レイヤー 3 ネットワークデバイス、またはサーバーとユーザー間のレイヤー 2 ネットワークブリッジとしてインストールできます。通常は会社のルーターまたはファイアウォールの背後に設置できます。保護する Web サーバーと、ユーザーがその Web サーバーにアクセスするハブまたはスイッチ間のトラフィックを傍受できる場所にインストールする必要があります。次に、リクエストをウェブサーバーに直接送信するのではなく Web App Firewall に送信し、ユーザーに直接送信するのではなく Web App Firewall に応答するようにネットワークを構成します。Web App Firewall は、内部ルールセットとユーザーによる追加や変更の両方を使用して、トラフィックを最終宛先に転送する前にフィルタリングします。有害であると検出したアクティビティをブロックまたはレンダリングし、残りのトラフィックを Web サーバに転送します。次の図は、フィルタリングプロセスの概要を示しています。
注：
この図では、着信トラフィックへのポリシーの適用は省略されています。このスライドは、ポリシーがすべての要求を処理するセキュリティ設定を示しています。また、この設定では、シグニチャオブジェクトが設定され、プロファイルに関連付けられ、セキュリティチェックが設定されています。
図1：Web App Firewall フィルタリングのフローチャート
Web App Firewall フローチャート
図が示すように、ユーザーが保護された Web サイトの URL をリクエストすると、Web App Firewall は最初にそのリクエストを調べ、署名と一致しないことを確認します。要求が署名と一致する場合、NetScaler Web App Firewallはエラーオブジェクト（Web App Firewallアプライアンス上にあり、インポート機能を使用して構成できるWebページ）を表示するか、指定されたエラーURL（エラーページ）に要求を転送します。署名はセキュリティチェックほど多くのリソースを必要としないため、セキュリティチェックを実行する前に署名によって検出された攻撃を検出して阻止することで、サーバーの負荷を軽減できます。
リクエストが署名検査に合格すると、Web App Firewall は有効になっているリクエストのセキュリティチェックを適用します。リクエストのセキュリティチェックは、リクエストがウェブサイトまたはウェブサービスに適しており、脅威となる可能性のある内容が含まれていないことを確認します。たとえば、セキュリティー検査では、リクエストが予期せぬタイプであるか、予期しないコンテンツをリクエストするか、予期せぬ悪意のある Web フォームデータ、SQL コマンド、またはスクリプトが含まれている可能性があることを示す標識がないか調べます。要求がセキュリティチェックに失敗した場合、Web App Firewallは要求をサニタイズしてからNetScaler ADCアプライアンス（またはNetScaler ADC仮想アプライアンス）に送り返すか、エラーオブジェクトを表示します。要求がセキュリティチェックに合格すると、NetScaler ADCアプライアンスに返送され、他の処理が完了し、保護されたWebサーバーに要求が転送されます。
Web サイトまたは Web サービスがユーザーに応答を送信すると、Web App Firewall は有効になっている応答セキュリティチェックを適用します。レスポンスセキュリティチェックでは、機密性の高い個人情報の漏えい、Web サイトの改ざんの兆候、または存在してはならないその他のコンテンツがないかどうかをチェックします。応答がセキュリティチェックに失敗した場合、Web App Firewall は存在してはならないコンテンツを削除するか、応答をブロックします。応答がセキュリティチェックに合格すると、NetScaler ADCアプライアンスに返信され、ユーザーに転送されます。

NetScaler Web App Firewall 機能

Web App Firewall 基本的な機能は、ポリシー、プロファイル、シグニチャです。これらは、 既知の Web 攻撃、不明な Web 攻撃、および WebApp Firewall しくみで説明されているハイブリッドセキュリティモデルを提供します。特に注意すべき点は、学習機能です。学習機能は、保護されたアプリケーションへのトラフィックを観察し、特定のセキュリティチェックに対して適切な構成設定を推奨しています。
インポート機能は、Web App Firewall にアップロードするファイルを管理します。これらのファイルは、Web App Firewall がさまざまなセキュリティチェックに使用したり、セキュリティチェックと一致する接続に応答したりするときに使用されます。
ログ、統計、およびレポート機能を使用して Web App Firewall のパフォーマンスを評価し、保護を強化する必要があるかどうかを特定できます。

NetScaler Web App Firewall ケーショントラフィックを変更する方法

NetScaler Web App Firewallは、以下を変更することにより、保護するWebアプリケーションの動作に影響を与えます。
  • Cookies
  • HTTP ヘッダー
  • フォーム/データ

NetScaler Web App Firewall セッションCookie

セッションの状態を維持するために、NetScaler Web App Firewallは独自のセッションCookie を生成します。このCookie は、WebブラウザとNetScaler ADC Webアプリケーションファイアウォールの間でのみ渡され、Webサーバーには渡されません。ハッカーがセッション Cookie を変更しようとすると、Web App Firewall は要求をサーバーに転送する前に Cookie をドロップし、要求を新しいユーザーセッションとして扱います。セッション Cookie は、Web ブラウザが開いている限り存在します。Web ブラウザを閉じると、アプリケーションファイアウォールのセッション Cookie は無効になります。セッションの状態には、クライアントがアクセスした URL とフォームの情報が保持されます。
設定可能な Web App Firewall セッション Cookie はcitrix_ns_idです。
NetScalerビルド12.1 54および13.0以降では、Cookie citrix_ns_idの整合性はセッションレスになり、アプライアンスによって生成されたセッションCookie の追加は強制されません。Cookie の設定について詳しくは、「 エンジン設定」を参照してください。

NetScaler Web App Firewall クッキー

多くのウェブアプリケーションは、ユーザーまたはセッション固有の情報を追跡するためにクッキーを生成します。この情報には、ユーザー設定やショッピングカートのアイテムなどがあります。Web アプリケーションの Cookie には、次の 2 つのタイプがあります。
  • パーシステントクッキー -これらのクッキーはコンピューター上にローカルに保存され、次回サイトにアクセスしたときに再び使用されます。このタイプのCookie には通常、ログオン、パスワード、設定などのユーザーに関する情報が含まれています。
  • セッションクッキーまたはトランジェントクッキー -これらのクッキーはセッション中にのみ使用され、セッションが終了すると破棄されます。このタイプの Cookie には、ショッピングカートのアイテムやセッション認証情報などのアプリケーション状態情報が含まれます。
ハッカーは、アプリケーションの Cookie を変更したり盗んだりして、ユーザーセッションを乗っ取ったり、ユーザーになりすましたりする可能性があります。アプリケーションファイアウォールは、アプリケーションクッキーをハッシュし、デジタル署名付きのクッキーをさらに追加することで、このような試みを防ぎます。アプリケーションファイアウォールは、クッキーを追跡することで、クライアントブラウザとアプリケーションファイアウォールの間でクッキーが変更されたり、危険にさらされたりしないようにします。アプリケーションファイアウォールはアプリケーションクッキーを変更しません。
NetScaler Web App Firewallは、アプリケーションクッキーを追跡するために以下のデフォルトクッキーを生成します。
  • パーシスタントクッキー: citrix_ns_id_wlf. 注意:wlfは永遠に生き続けるという意味です。
  • セッションクッキーまたはトランジェントクッキー: citrix_ns_id_wat. 注:の略は一時的に動作します。 アプリケーションクッキーを追跡するために、アプリケーションファイアウォールはパーシステントまたはセッションアプリケーションクッキーをグループ化し、すべてのクッキーをハッシュして署名します。したがって、アプリケーションファイアウォールは、すべての永続アプリケーション wlf Cookie を追跡する Cookie と、すべてのアプリケーションセッション wat Cookie を追跡する Cookie を 1 つ生成します。
次の表は、ウェブアプリケーションによって生成された Cookie に基づいてアプリケーションファイアウォールによって生成される Cookie の数と種類を示しています。
NetScaler Web App Firewall 前 変更後は以下の通り
1 つのパーシステントCookie パーシスタントCookie: citix_ns_id_wlf
1 つのトランジェントCookie トランジェントCookie: citix_ns_id_wat
複数のパーシステントクッキー、複数のトランジェントクッキー 1 つの永続Cookie: citrix_ns_id_wlf、1 つの一時Cookie: citix_ns_id_wat
NetScaler Web App Firewall では、アプリケーションCookie を暗号化できます。アプリケーションファイアウォールには、アプリケーションから送信されたセッション Cookie を残りのアプリケーションファイアウォールのセッションデータと一緒に保存し、クライアントには送信しないことでプロキシするオプションもあります。クライアントがアプリケーションファイアウォールのセッション Cookie を含むリクエストをアプリケーションに送信すると、アプリケーションファイアウォールは、元のアプリケーションにリクエストを送信する前に、アプリケーションから送信された Cookie をリクエストに挿入し直します。アプリケーションファイアウォールでは、HttpOnly フラグや Secure フラグを Cookie に追加することもできます。

アプリケーションファイアウォールが HTTP ヘッダーに与える影響

HTTPS リクエストと HTTPS レスポンスはどちらも、ヘッダーを使用して 1 つ以上の HTTPS メッセージに関する情報を送信します。ヘッダーは一連の行で、各行には名前の後にコロンとスペース、値が続きます。たとえば、Host ヘッダーの形式は次のとおりです。
Host: www.citrix.com
ヘッダーフィールドには、リクエストヘッダーとレスポンスヘッダーの両方で使用されるものもあれば、リクエストまたはレスポンスにのみ適しているものもあります。アプリケーションファイアウォールは、アプリケーションのセキュリティを維持するために、1 つ以上の HTTPS 要求または応答の一部のヘッダーを追加、変更、または削除する場合があります。

NetScaler Web App Firewall によってドロップされたリクエストヘッダー

キャッシュに関連するリクエストヘッダーの多くは、セッションのコンテキスト内のすべてのリクエストを表示するためにドロップされます。同様に、リクエストに Web サーバーが圧縮された応答を送信できるようにするエンコーディングヘッダーが含まれている場合、アプリケーションファイアウォールはこのヘッダーを削除します。これにより、非圧縮サーバー応答の内容が Web App Firewall によって検査され、機密データがクライアントに漏洩するのを防ぎます。
アプリケーションファイアウォールは、次のリクエストヘッダーを削除します。
  • 範囲 — 失敗したファイル転送または部分的なファイル転送からの回復に使用されます。
  • If-Range — キャッシュにすでにオブジェクトの一部が含まれている場合に、クライアントがオブジェクトの一部を取得できるようにします (条件付き GET)。
  • If-Modified-Since — このフィールドに指定された時間以降に要求されたオブジェクトが変更されていない場合、エンティティはサーバーから返されません。HTTP 304 変更されていないというエラーが表示されます。
  • If-None-Match — 最小限のオーバーヘッドで、キャッシュされた情報を効率的に更新できます。
  • Accept-Encoding — 特定のオブジェクトに使用できるエンコード方法 (gzip など)。

NetScaler Web App Firewall によって変更されたリクエストヘッダー

Web ブラウザが HTTP/1.0 以前のプロトコルを使用している場合、ブラウザは各応答を受信した後も TCP ソケット接続を継続的に開いたり閉じたりします。これにより、Web サーバーのオーバーヘッドが増え、セッション状態を維持できなくなります。HTTP/1.1 プロトコルでは、セッション中も接続を開いたままにできます。アプリケーションファイアウォールは、Web ブラウザが使用するプロトコルに関係なく、アプリケーションファイアウォールと Web サーバー間で HTTP/1.1 を使用するように次のリクエストヘッダーを変更します。 接続:keep-alive

NetScaler Web App Firewall によって追加されたリクエストヘッダー

アプリケーションファイアウォールはリバースプロキシとして機能し、セッションの元の送信元 IP アドレスをアプリケーションファイアウォールのIPアドレスに置き換えます。したがって、Web サーバーのログに記録されるすべての要求は、要求がアプリケーションファイアウォールから送信されたことを示しています。

NetScaler Web App Firewall によってドロップされた応答ヘッダー

アプリケーションファイアウォールは、クレジットカード番号の削除やコメントの削除などのコンテンツをブロックまたは変更する場合があり、その結果、サイズの不一致が生じる可能性があります。このようなシナリオを防ぐために、アプリケーションファイアウォールは次のヘッダーを削除します。
Content-Length — 受信者に送信されるメッセージのサイズを示します。 アプリケーションファイアウォールによって変更されたレスポンスヘッダー
アプリケーションファイアウォールによって変更される応答ヘッダーの多くは、キャッシュに関連しています。HTTP (S) 応答のキャッシュヘッダーを変更して、Web ブラウザーがローカルキャッシュを使用せずに、常に最新データのリクエストを Web サーバーに送信するように強制する必要があります。ただし、ASP アプリケーションによっては、個別のプラグインを使用して動的コンテンツを表示するため、データを一時的にブラウザにキャッシュする機能が必要な場合があります。FFC、URL クロージャー、CSRF チェックなどの高度なセキュリティ保護が有効になっているときにデータを一時的にキャッシュできるように、アプリケーションファイアウォールは次のロジックを使用してサーバー応答のキャッシュ制御ヘッダーを追加または変更します。
  • サーバーが Pragma: no-cache を送信した場合、アプリケーションファイアウォールは変更を行いません。
  • クライアントリクエストが HTTP 1.0 の場合、アプリケーションファイアウォールは Pragma: no-cache を挿入します。
  • クライアントリクエストが HTTP 1.1 で、Cache-Control: no-store が設定されている場合、アプリケーションファイアウォールは変更を行いません。
  • クライアントリクエストが HTTP 1.1 で、サーバーレスポンスの Cache-Control ヘッダーにストアもキャッシュディレクティブもない場合、アプリケーションファイアウォールは変更を行いません。
  • クライアント要求が HTTP 1.1 で、サーバーレスポンスに「キャッシュ制御ヘッダーなし」または「キャッシュ制御ヘッダーにストアなし」または「キャッシュなし」ディレクティブがない場合、アプリケーションファイアウォールは次のタスクを実行します。
  1. キャッシュコントロールを挿入します。max-age=3、再検証が必要、非公開です。
  2. X-Cache-Control-Orig = キャッシュコントロールヘッダーの元の値を挿入します。
  3. 最終更新ヘッダーを削除します。
  4. Etagの代わりになります。
  5. サーバーから送信された有効期限ヘッダーの X-Expires-Orig=オリジナル値を挿入します。
  6. Expires Headerを変更し、Webページの有効期限を過去に設定して、常に再度取得されるようにします。
  7. Accept-Ranges を変更し、それを「なし」に設定します。
アプリケーションファイアウォールが StripComments、X-out/Remove SafeObject、xout、クレジットカードまたは URL 変換の削除などの応答を変更したときに、クライアントブラウザに一時的にキャッシュされたデータを置き換えるために、アプリケーションファイアウォールは次のアクションを実行します。
  1. クライアントに転送する前に、Last-Modified をサーバーから削除します。
  2. Etag をアプリケーションファイアウォールによって決定された値に置き換えます。

NetScaler Web App Firewall によって追加されたレスポンスヘッダー

  • Transfer-Encoding: チャンク。このヘッダーは、応答を送信する前に応答の全長がわからなくても、情報をクライアントにストリーミングします。content-length ヘッダーが削除されているため、このヘッダーは必須です。
  • Set-Cookie: アプリケーションファイアウォールによって追加された Cookie。
  • Xet-Cookie: セッションが有効で、キャッシュ内の応答の有効期限が切れていない場合は、キャッシュから配信でき、セッションはまだ有効であるため、新しい Cookie を送信する必要はありません。このようなシナリオでは、セットクッキーは Xet-Cookie に変更されます。Web ブラウザ用。

フォームデータへの影響

アプリケーションファイアウォールは、サーバーから送信された元のフォームの内容を変更しようとする攻撃から保護します。また、クロスサイトリクエスト偽造攻撃からも保護できます。アプリケーションファイアウォールは、隠しフォームタグ as_fid をページに挿入することで実行されます。
例：<input type="hidden" name="as_fid" value="VRgWq0I196Jmg/+LOY7C" />
隠しフィールド as_fid はフィールドの一貫性を保つために使用されます。Application Firewall はこのフィールドを使用して、隠しフィールドの名前と値のペアを含むフォームのすべてのフィールドを追跡し、サーバーから送信されたフォームのフィールドがクライアント側で変更されないようにします。また、CSRFチェックでは、この独自のフォームタグ as_fid を使用して、ユーザーが送信したフォームがこのセッションでユーザーに提供され、ハッカーがユーザーセッションを乗っ取ろうとしていないことを確認します。

セッションレスフォームチェック

アプリケーションファイアウォールには、セッションレスフィールドの一貫性を使用してフォームデータを保護するオプションもあります。これは、フォームに動的な隠しフィールドが多数あり、アプリケーションファイアウォールによるセッションあたりのメモリ割り当て量が多くなる可能性があるアプリケーションに役立ちます。セッションレスフィールドの一貫性チェックは、構成された設定に基づいて、POST リクエストのみ、または GET リクエストと POST リクエストの両方に別の隠しフィールド as_ffc_field を挿入することによって実行されます。アプリケーションファイアウォールは、フォームをクライアントに転送するときに GET メソッドを POST に変更します。その後、アプライアンスはメソッドをサーバーに送信するときに、メソッドを GET に戻します。as_ffc_field の値は、送信されるフォームの暗号化されたダイジェストを含むため、大きくなる可能性があります。以下は、セッションレスフォームチェックの例です。
<input type="hidden" name="as_ffc_field" value="CwAAAAVIGLD/luRRi1Wu1rbYrFYargEDcO5xVAxsEnMP1megXuQfiDTGbwk0fpgndMHqfMbzfAFdjwR+TOm1oT
+u+Svo9+NuloPhtnbkxGtNe7gB/o8GlxEcK9ZkIIVv3oIL/nIPSRWJljgpWgafzVx7wtugNwnn8/GdnhneLCJTaYU7ScnC6LexJDLisI1xsEeONWt8Zm
+vJTa3mTebDY6LVyhDpDQfBgI1XLgfLTexAUzSNWHYyloqPruGYfnRPw+DIGf6gGwn1BYLEsRHKNbjJBrKpOJo9JzhEqdtZ1g3bMzEF9PocPvM1Hpvi5T6VB
/YFunUFM4f+bD7EAVcugdhovzb71CsSQX5+qcC1B8WjQ==" />

HTML コメントストリッピング

アプリケーションファイアウォールには、応答に含まれるすべての HTML コメントをクライアントに送信する前に削除するオプションもあります。これはフォームだけでなく、すべての回答ページに影響します。アプリケーションファイアウォールは、「<!」の間に埋め込まれたテキストを見つけて削除します。-」と「->」コメントタグ。タグはそのままで、HTML ソースコードのその場所にコメントが存在したことを示すものです。他の HTML または JavaScript タグに埋め込まれたテキストは無視されます。 一部のアプリケーションは、コメントタグに JavaScript が誤って埋め込まれていると、正しく動作しないことがあります。Application Firewall によってコメントが削除される前と後のページソースコードを比較すると、削除されたコメントに必要な JavaScript が埋め込まれているかどうかを確認するのに役立ちます。

クレジットカード保護

アプリケーションファイアウォールには、応答のヘッダーと本文を検査し、応答をクライアントに転送する前にクレジットカード番号を削除または消去するオプションがあります。現在、アプリケーションファイアウォールは、アメリカンエキスプレス、ダイナースクラブ、ディスカバー、JCB、マスターカード、Visaなどの主要なクレジットカードを保護しています。x-out アクションは Block アクションとは独立して動作します。

安全なオブジェクト保護

クレジットカード番号と同様に、Application Firewall Safe Objectセキュリティチェックを使用して応答内の機密コンテンツを削除または消去することで、他の機密データの漏洩を防ぐことができます。

クロスサイトスクリプティングはアクションを変える

トランスフォームでクロスサイトスクリプティングを有効にすると、Web App Firewall "<" into "%26lt;" and ">" into "%26gt;" のリクエストが変更されます。Web App Firewall の CheckRequestHeaders 設定が有効になっている場合、Web App Firewall はリクエストヘッダーを検査し、ヘッダーと Cookie 内のこれらの文字も変換します。変換アクションは、サーバーから最初に送信された値をブロックまたは変換しません。クロスサイトスクリプティングには、Web App Firewall で許可されているデフォルトの属性とタグのセットがあります。拒否されたクロスサイトスクリプティングパターンのデフォルトリストも提供されています。これらは、シグネチャオブジェクトを選択し、GUI の「 SQL/クロスサイトスクリプティングパターンの管理」ダイアログをクリックすることでカスタマイズできます 。

SQL 特殊文字の変換

アプリケーションファイアウォールには、SQL 特殊文字に関する次のデフォルト変換ルールがあります。
ライセンス 変更後は以下の通り トランスフォーメーション
'(一重引用符、つまり %27) " もう一つの一重引用符
\ (%5C のバックスラッシュ) 別のバックスラッシュが追加されました
; (%3B のセミコロン) 落下しました
特殊文字の変換が有効で、checkRequestHeaders が ON に設定されている場合、特殊文字の変換はヘッダーとクッキーでも行われます。 注:User-Agent、Accept-Encoding などの一部のリクエストヘッダーには通常セミコロンが含まれており、SQL 変換の影響を受ける可能性があります。

Expect ヘッダーが破損するNetScaler Web App Firewall 動作

  1. NetScalerがEXPECTヘッダーを含むHTTPリクエストを受信するたびに、NetScalerはバックエンドサーバーに代わって EXPECT: 100-continue レスポンスをクライアントに送信します。
  2. この動作は、要求をサーバーに転送する前に要求全体に対してアプリケーションファイアウォール保護を実行する必要があり、NetScalerは要求全体をクライアントから取得する必要があるためです。
  3. 100 continue 応答を受け取ると、クライアントはリクエストの残りの部分を送信してリクエストを完了します。
  4. その後、NetScalerはすべての保護を実行し、要求をサーバーに転送します。
  5. NetScalerがリクエスト全体を転送すると、最初のリクエストで受信したEXPECTヘッダーは古くなり、NetScalerはこのヘッダーを破損してサーバーに送信します。
  6. 要求を受信したサーバーは、破損しているヘッダーを無視します。