Citrix ADC

Citrix Webアプリケーションファイアウォールの概要

Citrix Web App Firewall は、セキュリティ侵害、データの損失、および機密性の高いビジネス情報や顧客情報にアクセスするWebサイトへの不正な変更を防止します。これは、要求と応答の両方をフィルタリングし、悪意のある活動の証拠を調べて、そのような活動を示すものをブロックすることによって行われます。あなたのサイトは、一般的なタイプの攻撃からだけでなく、新しい、まだ未知の攻撃からも保護されています。Web App Firewall は、Web サーバーや Web サイトを不正アクセスやハッカーや悪意のあるプログラムによる悪用から保護するだけでなく、レガシー CGI コードやスクリプト、他の Web フレームワーク、Web サーバーソフトウェア、および基盤となるオペレーティングシステムにおけるセキュリティの脆弱性に対する保護を提供します。

Citrix Web App Firewall は、スタンドアロンアプライアンスとして、またはCitrix ADC仮想アプライアンス(VPX)の機能として利用できます。Web App Firewall のマニュアルでは、Citrix ADC という用語は、Web App Firewall が実行されているプラットフォームを指します。プラットフォームが専用のファイアウォールアプライアンス、他の機能も構成されているCitrix ADC、Citrix ADC VPXのいずれであっても、Web App Firewall が実行されているプラットフォームを指します。

Web App Firewall を使用するには、保護された Web サイトに設定したルールに違反する接続をブロックするセキュリティ構成を少なくとも 1 つ作成する必要があります。作成するセキュリティ構成の数は、Web サイトの複雑さによって異なります。場合によっては、1 つの構成で十分です。特に、インタラクティブ Web サイト、データベースサーバーにアクセスする Web サイト、ショッピングカート付きのオンラインストアを含む場合は、特定の種類に対して脆弱でないコンテンツに多大な労力を浪費することなく、機密データを最適に保護するために、いくつかの異なる構成が必要になる場合があります。攻撃を阻止します。グローバル設定のデフォルトは、すべてのセキュリティ構成に影響するままにしておくことがよくあります。ただし、構成の他の部分と競合する場合や、カスタマイズする場合は、グローバル設定を変更できます。

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

Web アプリケーションセキュリティは、HTTP プロトコルと HTTPS プロトコルを使用して通信するコンピュータやプログラムのネットワークセキュリティです。これは、セキュリティ上の欠陥や弱点がたくさんある非常に広い領域です。サーバーとクライアントの両方のオペレーティングシステムにはセキュリティ上の問題があり、攻撃に対して脆弱です。CGI、Java、JavaScript、PERL、PHPなどのWebサーバーソフトウェアおよびWebサイト対応技術には、根本的な脆弱性があります。Web 対応アプリケーションと通信するブラウザやその他のクライアントアプリケーションにも脆弱性があります。訪問者とのやりとりを可能にするサイトを含め、最も単純な HTML の技術を使用する Web サイトには、多くの場合、独自の脆弱性があります。

以前は、セキュリティ侵害はしばしば面倒でしたが、今日ではほとんどそうではありません。たとえば、ハッカーが Web サーバーへのアクセスを取得し、Web サイトに不正な変更 (改ざん) を行った攻撃が一般的でした。彼らは通常、仲間のハッカーに自分のスキルを実証したり、標的を絞った人や会社を恥ずかしい超えて何のモチベーションを持っていたハッカーによって起動されました。しかし、現在のセキュリティ侵害のほとんどは、お金への欲求によって動機づけられています。大半は、機密性の高い潜在的に貴重な個人情報を取得すること、またはウェブサイトまたはウェブサーバーへの不正アクセスと制御を取得することを目的として、次の目標の一方または両方を達成しようとします。

特定の形態のWeb攻撃は、個人情報の取得に重点を置いています。このような攻撃は、攻撃者が完全に制御できないように十分に安全な Web サイトに対しても可能です。攻撃者が Web サイトから取得できる情報には、顧客名、住所、電話番号、社会保障番号、クレジットカード番号、医療記録、およびその他の個人情報が含まれます。攻撃者は、この情報を使用したり、他の人に販売することができます。このような攻撃によって得られる情報の多くは、法律によって保護され、そのすべてが習慣と期待によって保護されています。このタイプの違反は、個人情報を侵害するお客様にとって非常に重大な影響を及ぼす可能性があります。せいぜい、これらの顧客は、他の人が自分のクレジットカードを乱用したり、自分の名前に不正なクレジット口座を開設したり、自分の身元を完全に使用したりするのを防ぐために警戒しなければなりません(個人情報の盗難)。最悪の場合、顧客は台無しに信用格付けに直面する可能性があり、あるいは彼らは何の部分もなかった犯罪行為のために非難される。

その他の Web 攻撃は、Web サイトまたはそれが動作しているサーバー、またはその両方を制御する (または 妥協する) ことを目的としています。Web サイトまたはサーバーを制御するハッカーは、それを使用して、許可されていないコンテンツをホストしたり、別の Web サーバーでホストされているコンテンツのプロキシとして機能したり、迷惑なバルクメールを送信する SMTP サービスを提供したり、侵害された他の Web サーバーでのこのようなアクティビティをサポートする DNS サービスを提供することができます。侵害された Web サーバーでホストされているほとんどの Web サイトは、疑わしいまたは不正なビジネスを促進します。たとえば、フィッシング Web サイトや子搾取 Web サイトの大半は、侵害された Web サーバーでホストされています。

これらの攻撃からあなたのウェブサイトやWebサービスを保護するには、識別可能な特性を持つ既知の攻撃をブロックし、未知の攻撃から保護することができる多層防御が必要です。これは多くの場合、あなたのウェブサイトへの通常のトラフィックとは異なって見えるため、検出することができます。Web サービスをサポートします。

既知のウェブ攻撃

Web サイトの防御の第一線は、存在することが知られており、Web セキュリティの専門家によって観察および分析された多数の攻撃に対する保護です。HTML ベースの Web サイトに対する一般的な攻撃には、次のようなものがあります。

  • バッファオーバーフロー攻撃。Web サーバーまたは基盤となるオペレーティングシステムがハング、クラッシュ、または攻撃者に基盤となるオペレーティングシステムへのアクセスを提供することを期待して、非常に長い URL、非常に長い Cookie、またはその他の非常に長い情報を Web サーバーに送信します。バッファオーバーフロー攻撃は、不正な情報にアクセスしたり、Web サーバにアクセスしたり、またはその両方を侵害したりするために使用できます。
  • クッキーのセキュリティ攻撃。通常、偽造された資格情報を使用して不正なコンテンツへのアクセスを取得することを期待して、変更された Cookie を Web サーバーに送信します。
  • 強制的なブラウジング。ホームページ上のハイパーリンクや Web サイト上のその他の一般的な開始 URL を使用して URL に移動することなく、Web サイト上の URL に直接アクセスする。強制的なブラウジングの個々のインスタンスは、単にあなたのウェブサイト上のページをブックマークしたが、存在しないコンテンツ、またはユーザーが直接アクセスしてはならないコンテンツへのアクセスを繰り返し試みたユーザーを示すことができ、多くの場合、ウェブサイトのセキュリティに対する攻撃を表します。強制ブラウジングは通常、不正な情報へのアクセスを得るために使用されますが、サーバーを侵害する試みでバッファオーバーフロー攻撃と組み合わせることもできます。
  • Web フォームのセキュリティ攻撃。不適切なコンテンツを Web フォームでウェブサイトへ送信する。不適切なコンテンツには、変更された非表示フィールド、英数字データのみを対象としたフィールドの HTML またはコード、短い文字列のみを受け入れるフィールド内の過度に長い文字列、整数のみを受け入れるフィールド内の英数字文字列、Web サイトにはないさまざまなデータが含まれます。は、そのWebフォームで受信することを期待しています。Web フォームのセキュリティ攻撃は、Web サイトから不正な情報を取得したり、Web サイトを完全に侵害したりするために使用できます。通常は、バッファオーバーフロー攻撃と組み合わせて使用します。

Webフォームセキュリティに対する2つの特殊なタイプの攻撃には、特に言及する必要があります。

  • SQL インジェクション攻撃。アクティブな SQL コマンドを Web フォームまたは URL の一部として送信する。SQL データベースでコマンドを実行させることを目的としています。SQL インジェクション攻撃は、通常、不正な情報を取得するために使用されます。
  • クロスサイトスクリプティング攻撃。Web ページ上の URL またはスクリプトを使用して、同一オリジンポリシーに違反します。これにより、スクリプトが別の Web サイトのコンテンツからプロパティを取得したり、コンテンツを変更したりすることを禁じます。スクリプトは、Web サイトの情報を取得してファイルを変更できるため、別の Web サイトのコンテンツへのスクリプトアクセスを許可すると、不正な情報を取得したり、Web サーバーを侵害したり、またはその両方を行う手段が攻撃者に提供される可能性があります。

通常、XML ベースの Web サービスに対する攻撃は、Web サービスへの不適切なコンテンツ送信の試行、または Web サービスに対するセキュリティ侵害の試みの 2 つのカテゴリのうち少なくとも 1 つに分類されます。XML ベースの Web サービスに対する一般的な攻撃には、次のようなものがあります。

  • 悪意のあるコードまたはオブジェクト。機密情報を直接取得したり、攻撃者に Web サービスまたは基になるサーバーの制御を与える可能性のあるコードまたはオブジェクトを含む XML リクエスト。
  • 不正な形式の XML 要求。W3C XML 仕様に準拠していないため、セキュリティで保護されていない Web サービスのセキュリティに違反する XML 要求
  • サービス拒否 (DoS) 攻撃。対象の Web サービスを圧倒し、正当なユーザが Web サービスへのアクセスを拒否するという目的で、大量に繰り返し送信される XML 要求。

XML ベースの標準的な攻撃に加えて、XML Web サービスおよび Web 2.0 サイトも SQL インジェクション攻撃やクロスサイトスクリプティング攻撃に対して脆弱です。

  • SQL インジェクション攻撃。アクティブな SQL コマンドを XML ベースのリクエストで送信し、SQL データベースでコマンドを実行することを目的としています。HTML SQL インジェクション攻撃と同様に、XML SQL インジェクション攻撃は通常、不正な情報を取得するために使用されます。
  • クロスサイトスクリプティング攻撃。XML ベースのアプリケーションに含まれるスクリプトを使用して、同一オリジンポリシーに違反します。このポリシーでは、スクリプトが別のアプリケーションのコンテンツからプロパティを取得したり、コンテンツを変更したりすることはできません。スクリプトは XML アプリケーションを使用して情報を取得してファイルを変更できるため、別のアプリケーションに属するコンテンツへのスクリプトアクセスを許可すると、不正な情報を取得したり、アプリケーションを侵害したり、またはその両方を行う手段が攻撃者に与えられる可能性があります。

既知の Web 攻撃は、通常、特定の攻撃に対して常に現れ、正当なトラフィックには現れない特定の特性(シグニチャ)に対して Web サイトトラフィックをフィルタリングすることによって阻止できます。このアプローチには、比較的少ないリソースを必要とし、偽陽性のリスクが比較的少ないという利点があります。したがって、Web サイトや Web サービスに対する攻撃に対抗するうえで役立つツールであり、ほとんど知られている Web 攻撃を傍受する基本的なシグニチャ保護の設定は簡単です。

不明なウェブ攻撃

ウェブサイトやアプリケーションに対する最大の脅威は、既知の攻撃からではなく、未知の攻撃から来ています。ほとんどの未知の攻撃は、2 つのカテゴリに分類されます。セキュリティ会社がまだ効果的な防御を開発していない新規に起動された攻撃 (ゼロデイ攻撃) と、多くの Web サイトや Web サービスではなく、特定の Web サイトや Web サービスに対する慎重な標的攻撃 (槍攻撃) です。これらの攻撃は、既知の攻撃と同様に、通常、機密性の高い個人情報を取得し、Web サイトまたは Web サービスを侵害し、さらなる攻撃、またはその両方に使用することを目的としています。

ゼロデイ攻撃は、すべてのユーザーにとって大きな脅威です。通常、これらの攻撃は既知の攻撃と同じタイプです。ゼロデイ攻撃には、注入された SQL、クロスサイトスクリプト、クロスサイトリクエストフォージェリ、または既知の攻撃に似た別のタイプの攻撃が含まれます。ほとんどの場合、対象となるソフトウェア、Web サイト、または Web サービスの開発者が認識していないか、または学習したばかりの脆弱性を対象としています。したがって、セキュリティ会社は通常、これらの攻撃に対する防御策を開発しておらず、たとえそうであっても、ユーザーは通常、パッチを入手してインストールしたり、これらの攻撃から保護するために必要な回避策を実行したりしていません。ゼロデイ攻撃の発見から防御の可用性(脆弱性ウィンドウ)までの時間は短くなっていますが、加害者は、多くの Web サイトや Web サービスが攻撃に対する特定の保護を欠いている数時間または数日で数えることができます。

スピア攻撃は大きな脅威ですが、より選択されたユーザーグループにとっては大きな脅威です。スピア攻撃の一般的なタイプであるスピアフィッシュは、通常、特定の銀行や金融機関の顧客、または特定の会社や組織の従業員を対象としています。多くの場合、その銀行や金融機関の実際の通信に精通しているユーザーが認識できることを粗大に書かれた偽造である他のフィッシュとは異なり、スピアフィッシュは手紙完璧で非常に説得力があります。彼らは、最初の一見では、見知らぬ人が知っているか、取得することができるべきではない個人に固有の情報を含めることができます。したがって、スピアフィッシャーは自分のターゲットを説得して、要求された情報を提供することができます。フィッシャーは、アカウントを略奪したり、他の情報源から不正に取得したお金を処理したり、他の機密情報にアクセスしたりできます。

これらのタイプの攻撃には、標準シグニチャと同様に、特定の特性を探すスタティックパターンを使用することはできませんが、通常は検出できる特定の特性があります。この種の攻撃を検出するには、ヒューリスティックフィルタリングやポジティブなセキュリティモデルシステムなど、より高度でリソース集約的なアプローチが必要です。ヒューリスティックフィルタリングは、特定のパターンではなく、動作のパターンのために見えます。ポジティブセキュリティモデルシステムは、保護している Web サイトまたは Web サービスの通常の動作をモデル化し、その通常使用モデルに適合しない接続をブロックします。URL ベースおよび Web フォームベースのセキュリティチェックは、Web サイトの通常の使用をプロファイルし、ヒューリスティックとポジティブなセキュリティの両方を使用して、異常なトラフィックや予期しないトラフィックをブロックし、ユーザが Web サイトとやり取りする方法を制御します。ヒューリスティックとポジティブなセキュリティの両方が、適切に設計および導入され、シグニチャが見逃すほとんどの攻撃を捕捉できます。ただし、シグニチャよりもかなり多くのリソースを必要とするため、誤検知を避けるために適切に設定する時間を費やす必要があります。したがって、通常、主要な防御線としてではなく、シグネチャへのバックアップやその他のリソース集約の少ないアプローチとして使用されます。

シグニチャに加えてこれらの高度な保護を構成することで、ハイブリッドセキュリティモデルを作成します。これにより、Web App Firewall は、既知の攻撃と未知の攻撃の両方に対して包括的な保護を提供できます。

Citrix Webアプリケーションファイアウォールの仕組み

Web App Firewall をインストールするときに、ポリシー、プロファイル、およびシグニチャオブジェクトで構成される初期セキュリティ設定を作成します。ポリシーは、フィルタリングするトラフィックを識別する規則であり、トラフィックがフィルタリングされたときに許可またはブロックする動作のパターンとタイプがプロファイルによって識別されます。シグニチャと呼ばれる最も単純なパターンは、プロファイル内ではなく、プロファイルに関連付けられたシグニチャオブジェクト内で指定されます。

シグニチャは、既知の攻撃タイプに一致する文字列またはパターンです。Web App Firewall には、7 つのカテゴリに数千を超えるシグニチャが含まれており、それぞれが特定のタイプの Web サーバーおよび Web コンテンツに対する攻撃を狙っています。新しい脅威が特定されると、Citrix は新しい署名でリストを更新します。設定時に、保護する必要がある Web サーバとコンテンツに適したシグニチャカテゴリを指定します。シグニチャは、処理オーバーヘッドが低く、優れた基本的な保護を提供します。アプリケーションに特殊な脆弱性がある場合、またはシグニチャが存在しない攻撃を検出した場合は、独自のシグニチャを追加できます。

より高度な保護をセキュリティチェックと呼びます。セキュリティチェックとは、攻撃を示したり、保護された Web サイトや Web サービスに対する脅威となる可能性のある特定のパターンや動作の種類に対する要求をより厳密にアルゴリズム的に検査することです。たとえば、セキュリティを侵害する可能性のある特定の種類の操作を実行しようとする要求や、社会保障番号やクレジットカード番号などの機密性の高い個人情報を含む応答を識別できます。構成時に、保護する必要がある Web サーバーとコンテンツに適したセキュリティー検査を指定します。セキュリティー検査には制限があります。それらの多くは、適切な例外(緩和)を設定するときに追加しないと、正当な要求と応答をブロックできます。Web サイトの通常の使用を観察し、推奨される例外を作成する適応学習機能を使用すると、必要な例外を特定することは難しくありません。

Web App Firewall は、サーバーとユーザー間のレイヤー 3 ネットワークデバイスまたはレイヤー 2 ネットワークブリッジとしてインストールできます。通常は、会社のルーターまたはファイアウォールの背後にあります。保護する Web サーバと、ユーザがそれらの Web サーバにアクセスするためのハブまたはスイッチ間のトラフィックを傍受できる場所にインストールする必要があります。次に、Web サーバーに直接ではなく Web App Firewall にリクエストを送信し、ユーザーに直接ではなく Web App ファイアウォールに応答するようにネットワークを設定します。Web App Firewall は、内部ルールセットとユーザーの追加と変更の両方を使用して、最終的な宛先に転送する前にトラフィックをフィルタリングします。有害であると検出したアクティビティをブロックまたはレンダリングし、残りのトラフィックを Web サーバに転送します。次の図は、フィルタリングプロセスの概要を示しています。

注:

この図は、着信トラフィックへのポリシーの適用を省略しています。このスライドは、ポリシーがすべての要求を処理するセキュリティ設定を示しています。また、この設定では、シグニチャオブジェクトが設定され、プロファイルに関連付けられ、セキュリティチェックが設定されています。

図1:Web App Firewall フィルタリングフローチャート

Web App Firewall フローチャート

図に示すように、ユーザーが保護された Web サイトで URL を要求すると、Web App Firewall は最初に要求を調べ、署名と一致しないことを確認します。要求が署名と一致する場合、Citrix Webアプリケーションファイアウォールは、エラーオブジェクト(Web App Firewall アプライアンス上に配置され、インポート機能を使用して構成できるWebページ)を表示するか、指定されたエラーURL(エラーページ)に要求を転送します。シグニチャにはセキュリティチェックほど多くのリソースが必要ないため、セキュリティチェックを実行する前にシグニチャによって検出された攻撃を検出して停止すると、サーバの負荷が軽減されます。

要求が署名検査に合格すると、Web App Firewall は有効になっている要求セキュリティー検査を適用します。リクエストのセキュリティチェックでは、リクエストが Web サイトまたは Web サービスに適しており、脅威となる可能性のある情報が含まれていないことを確認します。たとえば、セキュリティー検査では、リクエストが予期せぬタイプであるか、予期しないコンテンツをリクエストするか、予期せぬ悪意のある Web フォームデータ、SQL コマンド、またはスクリプトが含まれている可能性があることを示す標識がないか調べます。要求がセキュリティチェックに失敗した場合、Web App Firewall は要求をサニタイズしてからCitrix ADCアプライアンス(またはCitrix ADC仮想アプライアンス)に送り返すか、エラーオブジェクトを表示します。要求がセキュリティチェックに合格すると、Citrix ADCアプライアンスに返送され、他の処理が完了し、保護されたWebサーバーに要求が転送されます。

Web サイトまたは Web サービスがユーザーに応答を送信すると、Web App Firewall は有効になっている応答セキュリティー検査を適用します。応答セキュリティチェックでは、機密性の高い個人情報の漏洩、Web サイトの改変の兆候、または存在してはならないその他のコンテンツの応答を調べます。応答がセキュリティチェックに失敗した場合、Web App Firewall は存在しないコンテンツを削除するか、応答をブロックします。応答がセキュリティチェックに合格すると、Citrix ADCアプライアンスに返信され、ユーザーに転送されます。

Citrix Webアプリケーションファイアウォールの機能

Web App Firewall の基本機能は、ポリシー、プロファイル、およびシグニチャで、「既知の Web 攻撃」、「不明な Web 攻撃」、「Web App Firewall 仕組み」で説明されているように、ハイブリッドセキュリティモデルを提供します。特に注意すべき点は、学習機能です。学習機能は、保護されたアプリケーションへのトラフィックを観察し、特定のセキュリティチェックに対して適切な構成設定を推奨しています。

インポート機能は、Web App Firewall にアップロードするファイルを管理します。これらのファイルは、Web App Firewall によってさまざまなセキュリティチェックで使用され、またはセキュリティチェックに一致する接続に応答するときに使用されます。

ログ、統計情報、およびレポート機能を使用して、Web App Firewall ールのパフォーマンスを評価し、追加の保護の必要性を特定できます。

Citrix Webアプリケーションファイアウォールによるアプリケーショントラフィックの変更方法

Citrix Webアプリケーションファイアウォールは、保護するWebアプリケーションの動作に影響を与えます。

  • Cookies
  • HTTP ヘッダー
  • フォーム/データ

Citrix Webアプリケーションファイアウォールのセッションクッキー

セッションの状態を維持するために、Citrix ADC Web App Firewallは独自のセッションCookieを生成します。このCookieは、WebブラウザとCitrix ADC Webアプリケーションファイアウォールの間でのみ渡され、Webサーバーには渡されません。いずれかのハッカーがセッション cookie を変更しようとすると、アプリケーションファイアウォールは、要求をサーバーに転送する前に cookie を削除し、要求を新しいユーザーセッションとして扱います。セッションクッキーは、Webブラウザが開いている限り存在します。Web ブラウザーを閉じると、アプリケーションファイアウォールのセッション cookie が有効になります。

構成可能な Web App Firewall セッション Cookie はcitrix_ns_idです。

Citrix Web App Firewall クッキー

多くのWebアプリケーションは、ユーザーまたはセッション固有の情報を追跡するためにCookieを生成します。この情報には、ユーザー設定やショッピングカート商品などがあります。Web アプリケーション Cookie は、次の 2 つのタイプのいずれかになります。

  • パーシステントクッキー -これらのクッキーはコンピュータにローカルに保存され、次回サイトにアクセスしたときに再び使用されます。通常、このタイプの Cookie には、ログオン、パスワード、設定などのユーザーに関する情報が含まれます。
  • セッションまたは一時的なクッキー -これらのクッキーは、セッションの期間中のみ使用され、セッションが終了した後に破棄されます。このタイプのクッキーには、ショッピングカートアイテムやセッション認証情報などのアプリケーション状態情報が含まれます。

ハッカーは、ユーザーセッションをハイジャックしたり、ユーザーとしてマスカレードするために、アプリケーションクッキーを変更または盗むことができます。アプリケーションファイアウォールは、アプリケーションCookieをハッシュし、デジタル署名とともに追加のCookieを追加することで、このような試みを防止します。アプリケーションファイアウォールは、クッキーを追跡することにより、クライアントブラウザとアプリケーションファイアウォールの間でクッキーが変更されたり、侵害されたりしないことを保証します。アプリケーションファイアウォールは、アプリケーション Cookie を変更しません。

Citrix Webアプリケーションファイアウォールは、アプリケーションCookieを追跡するために、次のデフォルトのCookieを生成します。

  • パーシステントCookie:citrix_ns_id_wlf。注:wlfの略は永遠に生きる。
  • セッションCookieまたは一時Cookie:citrix_ns_id_wat。注:watの略は過渡的に動作します。 アプリケーション Cookie を追跡するために、アプリケーションファイアウォールは、永続アプリケーション Cookie またはセッションアプリケーション Cookie をまとめてグループ化し、すべての Cookie をまとめてハッシュおよび署名します。したがって、アプリケーションファイアウォールは、すべての永続的なアプリケーションwlf Cookie を追跡する 1 つの Cookie を生成し、すべてのアプリケーションセッションwat Cookie を追跡する 1 つの Cookie を生成します。

Web App Firewall は、Web アプリケーションが Cookie を生成するかどうかにかかわらず、常にアプリケーションファイアウォールセッション Cookie を生成します。

次の表は、Web アプリケーションによって生成された Cookie に基づいて、アプリケーションファイアウォールによって生成された Cookie の数と種類を示しています。

Citrix ADC Web App Firewall 前 変更後は以下の通り
クッキーなし セッションクッキー:citrix_ns_id
1 つの永続クッキー セッションクッキー:citrix_ns_id
2つの永続的なクッキー アプリケーションからの 2 つの元の永続クッキー。セッションクッキー:citrix_ns_id、永続クッキー:citrix_ns_id_wlf
1 つの永続クッキー、1 つの一時クッキー アプリケーションからの 1 つの元の永続的なクッキー。アプリケーションからの 1 つの元のセッションクッキー。セッションクッキー:citrix_ns_id、パーシステントクッキー:citrix_ns_id_wlf、一時クッキー:citix_ns_id_wat

Citrix Web App Firewall では、アプリケーションCookieを暗号化できます。また、アプリケーションファイアウォールは、アプリケーションによって送信されたセッションクッキーをプロキシするオプションを提供します。これは、アプリケーションファイアウォールのセッションデータの残りの部分と一緒に保存し、クライアントに送信しません。クライアントが、アプリケーションファイアウォールのセッション Cookie を含む要求をアプリケーションに送信すると、アプリケーションファイアウォールは、要求を元のアプリケーションに送信する前に、送信された Cookie を要求に挿入し直します。アプリケーションファイアウォールは、HttpOnlyおよび/またはセキュアフラグをクッキーに追加することもできます。

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

HTTP リクエストと HTTP レスポンスの両方で、ヘッダーを使用して HTTP メッセージに関する情報を送信します。ヘッダーは、名前とコロン、スペース、および値を含む各行の一連の行です。たとえば、Host ヘッダーの形式は次のとおりです。

Host: www.citrix.com

ヘッダーフィールドの中には、リクエストヘッダーとレスポンスヘッダーの両方で使用されるものもあれば、リクエストまたはレスポンスのいずれかにのみ適したものもあります。アプリケーションファイアウォールは、アプリケーションのセキュリティを維持するために、HTTP 要求または応答の一部のヘッダーを追加、変更、または削除することがあります。

Citrix Webアプリケーションファイアウォールによって削除された要求ヘッダー

キャッシュに関連する要求ヘッダーの多くは、セッションのコンテキスト内のすべての要求を表示するために、アプリケーションファイアウォールによって削除される可能性があります。同様に、要求に Web サーバーが圧縮応答を送信できるようにするエンコードヘッダーが含まれている場合、Application Firewall はこのヘッダーを削除して、圧縮されていないサーバー応答の内容を Application Firewall によって検査して、機密データがクライアントへ漏洩しないようにします。

アプリケーションファイアウォールは、次の要求ヘッダーを削除します。

  • Range:失敗したファイル転送または部分的なファイル転送からのリカバリに使用されます。
  • If-Range — クライアントがキャッシュ内にそのオブジェクトの一部がすでに含まれている場合に、部分的なオブジェクトを取得できるようにします (条件付き GET)。
  • If-Modified-Sins — 要求されたオブジェクトがこのフィールドに指定された時間以降に変更されていない場合、エンティティはサーバーから返されません。HTTP 304が変更されていないエラーが表示されます。
  • If-None-Match:最小限のオーバーヘッドで、キャッシュされた情報を効率的に更新できます。
  • Accept-Encoding — gzip などの特定のオブジェクトに対して許可されるエンコード方法。

Citrix Webアプリケーションファイアウォールによって変更された要求ヘッダー

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

Citrix Webアプリケーションファイアウォールによって追加された要求ヘッダー

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

Citrix Webアプリケーションファイアウォールによって削除されたレスポンスヘッダー

アプリケーションファイアウォールは、クレジットカード番号の削除やコメントの削除などのコンテンツをブロックまたは変更する場合があり、サイズが一致しない可能性があります。このようなシナリオを防ぐために、アプリケーションファイアウォールは、次のヘッダーを削除します。

[Content-Length] — 受信者に送信されるメッセージのサイズを示します。 アプリケーションファイアウォールによって変更された応答ヘッダー

アプリケーションファイアウォールによって変更された応答ヘッダーの多くは、キャッシュに関連しています。HTTP (S) 応答のキャッシュヘッダーを変更して、Web ブラウザーが常に Web サーバーに最新のデータを求める要求を送信し、ローカルキャッシュを使用しないようにする必要があります。ただし、ASP アプリケーションによっては、動的なコンテンツを表示するために個別のプラグインを使用する場合があり、データをブラウザに一時的にキャッシュする機能が必要な場合があります。FFC、URL 閉鎖、CSRF チェックなどの高度なセキュリティ保護が有効になっている場合に、データの一時的なキャッシュを許可するために、アプリケーションファイアウォールは、次のロジックを使用して、サーバー応答のキャッシュ制御ヘッダーを追加または変更します。

  • サーバーがプラグマを送信した場合:キャッシュなし、その後、アプリケーションファイアウォールは、任意の変更を行いません。
  • クライアント要求がHTTP 1.0である場合、アプリケーションファイアウォールは、プラグマを挿入します:キャッシュなし。
  • クライアント要求がHTTP 1.1で、キャッシュ制御:非ストアがある場合、アプリケーションファイアウォールは変更を行いません。
  • クライアント要求がHTTP 1.1であり、サーバー応答にストアまたはキャッシュディレクティブがないキャッシュ制御ヘッダーがある場合、アプリケーションファイアウォールは、任意の変更を行いません。

  • クライアント要求が HTTP 1.1 で、サーバー応答にキャッシュ制御ヘッダーがないか、キャッシュ制御ヘッダーにストアまたはキャッシュなしディレクティブがない場合、アプリケーションファイアウォールは次のタスクを完了します。
  1. キャッシュコントロールを挿入します:最大年齢 = 3、再検証する必要があります、プライベート。
  2. Inserts X-Cache-Control-orig = Original value of Cache-Control Header.
  3. 最終更新ヘッダーを削除します。
  4. ETAGを置き換えます。
  5. サーバーによって送信された期限切れヘッダーのX-Expire-Orig=元の値を挿入します。
  6. Expires ヘッダーを変更し、Web ページの有効期限を過去に設定するので、常に再び取得されます。
  7. 受け入れ範囲を変更し、noneに設定します。

アプリケーションファイアウォールが StripComments、X-out/Remove SafeObject、xout、クレジットカードまたは URL 変換の削除などの応答を変更したときに、クライアントブラウザーに一時的にキャッシュされたデータを置き換えるために、アプリケーションファイアウォールは以下のアクションを実行します。

  1. クライアントに転送する前に、サーバーから Last-Modified を削除します。
  2. ETag は、アプリケーションファイアウォールによって決定された値に置き換えます。

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

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

フォームデータの影響

アプリケーションファイアウォールは、サーバーから送信された元のフォームの内容を変更しようとする攻撃から保護します。また、クロスサイトリクエストフォージェリ攻撃から保護することもできます。アプリケーションファイアウォールは、ページに非表示のフォームタグ 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、マスターカード、およびビザ。x-out アクションは、[ブロック] アクションとは無関係に機能します。

安全な物体保護

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

XSS 変換アクション

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

SQL 特殊文字の変換

アプリケーションファイアウォールには、SQL 特殊文字に対する次のデフォルトの変換ルールがあります。

From To Transformation
’ (single quote that is, %27) Another single quote
\ (backslash that is %5C) |Another backslash added  
; (semicolon that is %3B)   Dropped

特殊文字の変換が有効になっており、CheckRequestHeadersがONに設定されている場合、特殊文字の変換もヘッダーとクッキーで発生します。 注:User-Agent、Accept-Encodingなどの一部のリクエストヘッダーにはセミコロンが含まれているため、SQL変換の影響を受ける可能性があります。

Citrix Web アプリケーションファイアウォールの動作で、Expect ヘッダーが破損します

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

Citrix Webアプリケーションファイアウォールの概要