Citrix Webアプリケーションファイアウォールの概要
Citrix Web App Firewallは、セキュリティ違反、データ損失、および機密のビジネス情報や顧客情報にアクセスするWebサイトへの不正な変更の可能性を防ぎます。これは、リクエストとレスポンスの両方をフィルタリングし、悪意のあるアクティビティの証拠がないか調べ、そのようなアクティビティを示すリクエストをブロックすることで行われます。あなたのサイトは、一般的なタイプの攻撃からだけでなく、新しい、まだ未知の攻撃からも保護されています。WebサーバーとWebサイトを不正アクセスから保護することに加えて、Web App Firewallは、レガシー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サイトの複雑さによって異なります。場合によっては、単一の構成で十分です。その他の場合、特にインタラクティブなWebサイト、データベースサーバーにアクセスするWebサイト、ショッピングカートを備えたオンラインストアなどの場合、特定の種類の攻撃に対して脆弱ではないコンテンツに多大な労力を費やすことなく機密データを最適に保護するために、いくつかの異なる構成が必要になる場合があります。グローバル設定のデフォルトは、すべてのセキュリティ構成に影響するままにしておくことがよくあります。ただし、構成の他の部分と競合する場合や、カスタマイズする場合は、グローバル設定を変更できます。
Webアプリケーションのセキュリティ
Web アプリケーションセキュリティは、HTTP プロトコルと HTTPS プロトコルを使用して通信するコンピュータやプログラムのネットワークセキュリティです。これは、セキュリティの欠陥や弱点がたくさんある広い領域です。サーバーとクライアントの両方のオペレーティングシステムにはセキュリティ上の問題があり、攻撃に対して脆弱です。CGI、Java、JavaScript、PERL、PHPなどのWebサーバーソフトウェアとWebサイト対応テクノロジには、根本的な脆弱性があります。Web 対応アプリケーションと通信するブラウザやその他のクライアントアプリケーションにも脆弱性があります。訪問者との対話を可能にするサイトを含む、最も単純なHTML以外のテクノロジーを使用するWebサイトには、多くの場合、独自の脆弱性があります。
以前は、セキュリティ侵害はしばしば面倒でしたが、今日ではほとんどそうではありません。たとえば、ハッカーがWebサーバーにアクセスし、Webサイトに不正な変更を加えた（改ざんした）攻撃は、以前は一般的でした。彼らは通常、仲間のハッカーに自分のスキルを実証したり、標的を絞った人や会社を恥ずかしい超えて何のモチベーションを持っていたハッカーによって起動されました。しかし、現在のセキュリティ侵害のほとんどは、お金への欲求によって動機づけられています。大多数は、次の目標の1つまたは両方を達成しようとします。機密で潜在的に価値のある個人情報を取得すること、またはWebサイトまたはWebサーバーへの不正アクセスと制御を取得すること。
特定の形態のWeb攻撃は、個人情報の取得に重点を置いています。これらの攻撃は、攻撃者が完全に制御するのを防ぐのに十分な安全性を備えたWebサイトに対しても可能であることがよくあります。攻撃者がWebサイトから取得できる情報には、顧客の名前、住所、電話番号、社会保障番号、クレジットカード番号、医療記録、およびその他の個人情報が含まれます。攻撃者は、この情報を使用したり、他の人に販売することができます。このような攻撃によって得られる情報の多くは、法律によって保護され、そのすべてが習慣と期待によって保護されています。このタイプの違反は、個人情報が危険にさらされている顧客に深刻な結果をもたらす可能性があります。せいぜい、これらの顧客は、他人が自分のクレジットカードを悪用したり、自分の名前で不正なクレジットアカウントを開設したり、自分のIDを完全に流用したり（個人情報の盗難）しないように警戒する必要があります。最悪の場合、顧客は台無しに信用格付けに直面する可能性があり、あるいは彼らは何の部分もなかった犯罪行為のために非難される。
他のWeb攻撃は、Webサイトまたはそれが動作するサーバー、あるいはその両方の制御を取得する（または 侵害する）ことを目的としています。Webサイトまたはサーバーの制御を取得したハッカーは、それを使用して、不正なコンテンツをホストしたり、別のWebサーバーでホストされたコンテンツのプロキシとして機能したり、SMTPサービスを提供して一方的なバルク電子メールを送信したり、DNSサービスを提供して他の侵害されたコンテンツでそのようなアクティビティをサポートしたりできますWebサーバー。侵害されたWebサーバーでホストされているほとんどのWebサイトは、疑わしい、または完全に不正なビジネスを促進しています。たとえば、ほとんどのフィッシングWebサイトと子エクスプロイテーションWebサイトは、侵害されたWebサーバーでホストされています。
これらの攻撃からWebサイトとWebサービスを保護するには、識別可能な特性を持つ既知の攻撃をブロックし、未知の攻撃から保護することができる多層防御が必要です。未知の攻撃は、WebサイトとWebサービスへの通常のトラフィックとは異なって見えるために検出されることがよくあります。
既知のウェブ攻撃
Webサイトの最初の防衛線は、存在することがわかっており、Webセキュリティの専門家によって監視および分析されている多数の攻撃に対する保護です。HTMLベースのWebサイトに対する一般的な攻撃の種類は次のとおりです。
- バッファオーバーフロー攻撃。長いURL、長いCookie、または長い情報をWebサーバーに送信すると、システムがハングしたり、クラッシュしたり、基盤となるオペレーティングシステムへの不正アクセスが提供されたりします。バッファオーバーフロー攻撃は、不正な情報にアクセスしたり、Web サーバにアクセスしたり、またはその両方を侵害したりするために使用できます。
- クッキーのセキュリティ攻撃。通常、偽造された資格情報を使用して不正なコンテンツへのアクセスを取得することを期待して、変更された Cookie を Web サーバーに送信します。
- 強制的なブラウジング。ホームページ上のハイパーリンクのあるURLやWebサイト上の他の一般的な開始URLに移動せずに、Webサイト上のURLに直接アクセスします。強制ブラウジングの個々のインスタンスは、ユーザーがWebサイトのページをブックマークしたことを示している可能性がありますが、存在しないコンテンツ、またはユーザーが直接アクセスしてはならないコンテンツに繰り返しアクセスしようとすると、Webサイトのセキュリティに対する攻撃を表すことがよくあります。強制ブラウジングは通常、不正な情報へのアクセスを得るために使用されますが、サーバーを侵害する試みでバッファオーバーフロー攻撃と組み合わせることもできます。
- Web フォームのセキュリティ攻撃。不適切なコンテンツをWebフォームでWebサイトに送信する。不適切なコンテンツには、変更された非表示フィールド、HTML、または英数字データのみを対象とするフィールドのコード、短い文字列のみを受け入れるフィールドの長すぎる文字列、整数のみを受け入れるフィールドの英数字文字列、およびワイドが含まれる可能性がありますあなたのウェブサイトがそのウェブフォームで受け取ることを期待していない他のさまざまなデータ。Webフォームのセキュリティ攻撃は、通常、バッファオーバーフロー攻撃と組み合わせて、Webサイトから不正な情報を取得するか、Webサイトを完全に侵害するために使用できます。
Webフォームセキュリティに対する2つの特殊なタイプの攻撃には、特に言及する必要があります。
- SQL インジェクション攻撃。SQLデータベースに1つまたは複数のコマンドを実行させることを目的として、アクティブなSQLコマンドをWebフォームまたはURLの一部として送信します。SQL インジェクション攻撃は、通常、不正な情報を取得するために使用されます。
- クロスサイトスクリプティング攻撃。ウェブページ上のURLまたはスクリプトを使用して、同一生成元ポリシーに違反します。これにより、スクリプトが別のウェブサイトのコンテンツからプロパティを取得したり、コンテンツを変更したりすることが禁止されます。スクリプトは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データベースにそのコマンドを実行させることを目的として、アクティブなSQLコマンドをXMLベースの要求で送信します。HTML SQL インジェクション攻撃と同様に、XML SQL インジェクション攻撃は通常、不正な情報を取得するために使用されます。
- クロスサイトスクリプティング攻撃。XML ベースのアプリケーションに含まれるスクリプトを使用して、同一オリジンポリシーに違反します。このポリシーでは、スクリプトが別のアプリケーションのコンテンツからプロパティを取得したり、コンテンツを変更したりすることはできません。スクリプトは XML アプリケーションを使用して情報を取得してファイルを変更できるため、別のアプリケーションに属するコンテンツへのスクリプトアクセスを許可すると、不正な情報を取得したり、アプリケーションを侵害したり、またはその両方を行う手段が攻撃者に与えられる可能性があります。
既知のWeb攻撃は通常、特定の攻撃に対して常に表示され、正当なトラフィックに表示されてはならない特定の特性（シグネチャ）に対してWebサイトトラフィックをフィルタリングすることで阻止できます。このアプローチには、比較的少ないリソースを必要とし、偽陽性のリスクが比較的少ないという利点があります。したがって、WebサイトやWebサービスへの攻撃に対抗し、基本的な署名保護を構成するための貴重なツールです。
不明なウェブ攻撃
Webサイトやアプリケーションに対する最大の脅威は、既知の攻撃ではなく、未知の攻撃によるものです。ほとんどの未知の攻撃は、セキュリティ会社がまだ効果的な防御を開発していない新たに開始された攻撃（ゼロデイ攻撃）と、多くの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サイトでURLを要求すると、Web App Firewallは最初にその要求を調べて、署名と一致しないことを確認します。リクエストが署名と一致する場合、Citrix Web Application Firewallはエラーオブジェクト（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 AppFirewallは有効になっている応答セキュリティチェックを適用します。応答セキュリティチェックでは、機密性の高い個人情報の漏洩、Webサイトの改ざんの兆候、または存在してはならないその他のコンテンツがないか応答を調べます。応答がセキュリティチェックに失敗した場合、Web App Firewallは、存在してはならないコンテンツを削除するか、応答をブロックします。応答がセキュリティチェックに合格すると、Citrix ADCアプライアンスに返信され、ユーザーに転送されます。
Citrix Webアプリケーションファイアウォールの機能
Web App Firewall 基本的な機能は、ポリシー、プロファイル、シグニチャです。これらは、 既知の Web 攻撃、不明な Web 攻撃、および WebApp 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 が有効になります。セッションの状態は、クライアントがアクセスしたURLとフォームの情報を維持します。
構成可能な Web App Firewall セッション Cookie はcitrix_ns_idです。
Citrix ADCビルド12.154および13.0以降では、Cookieの整合性はセッションレスであり、アプライアンスによって生成されたセッションCookie citrix_ns_id の追加を強制しません。
Citrix Web App Firewall クッキー
多くのWebアプリケーションは、ユーザーまたはセッション固有の情報を追跡するためにCookieを生成します。この情報は、ユーザー設定またはショッピングカートアイテムです。Web アプリケーション Cookie は、次の 2 つのタイプのいずれかになります。
- パーシステントクッキー -これらのクッキーはコンピュータにローカルに保存され、次回サイトにアクセスしたときに再び使用されます。通常、このタイプの Cookie には、ログオン、パスワード、設定などのユーザーに関する情報が含まれます。
- セッションCookieまたは一時Cookie- これらの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 をまとめてハッシュおよび署名します。したがって、アプリケーションファイアウォールは、すべての永続的なアプリケーションwlfCookie を追跡する 1 つの Cookie を生成し、すべてのアプリケーションセッションwatCookie を追跡する 1 つの Cookie を生成します。
次の表は、Web アプリケーションによって生成された Cookie に基づいて、アプリケーションファイアウォールによって生成された Cookie の数と種類を示しています。
| Citrix ADC Web App Firewall 前 | 変更後は以下の通り |
|---|---|
| 1 つの永続クッキー | 永続的なCookie： citix_ns_id_wlf
|
| 1つの一時的なCookie | 一時的なCookie： citix_ns_id_wat
|
| 複数の永続的なCookie、複数の一時的なCookie | 1つの永続的なCookie： citrix_ns_id_wlf、1つの一時的なCookie： citix_ns_id_wat
|
Citrix Web App Firewall では、アプリケーションCookieを暗号化できます。また、アプリケーションファイアウォールは、アプリケーションによって送信されたセッションクッキーをプロキシするオプションを提供します。これは、アプリケーションファイアウォールのセッションデータの残りの部分と一緒に保存し、クライアントに送信しません。クライアントが、アプリケーションファイアウォールのセッション Cookie を含む要求をアプリケーションに送信すると、アプリケーションファイアウォールは、要求を元のアプリケーションに送信する前に、送信された Cookie を要求に挿入し直します。アプリケーションファイアウォールは、HttpOnlyおよび/またはセキュアフラグをクッキーに追加することもできます。
アプリケーションファイアウォールが HTTP ヘッダーに与える影響
HTTP要求とHTTP応答はどちらも、ヘッダーを使用して1つ以上のHTTPのメッセージに関する情報を送信します。ヘッダーは、名前とコロン、スペース、および値を含む各行の一連の行です。たとえば、Host ヘッダーの形式は次のとおりです。
Host: www.citrix.com
ヘッダーフィールドの中には、リクエストヘッダーとレスポンスヘッダーの両方で使用されるものもあれば、リクエストまたはレスポンスのいずれかにのみ適したものもあります。アプリケーションファイアウォールは、アプリケーションのセキュリティを維持するために、1つ以上のHTTP要求または応答の一部のヘッダーを追加、変更、または削除する場合があります。
Citrix Webアプリケーションファイアウォールによって削除された要求ヘッダー
キャッシュに関連するリクエストヘッダーの多くは、セッションのコンテキスト内のすべてのリクエストを表示するために削除されます。同様に、リクエストにエンコードヘッダーが含まれていて、Webサーバーが圧縮応答を送信できるようにする場合、アプリケーションファイアウォールはこのヘッダーを削除するため、圧縮されていないサーバー応答の内容がWeb App Firewallによって検査され、クライアントへの機密データの漏洩が防止されます。
アプリケーションファイアウォールは、次の要求ヘッダーを削除します。
- Range：失敗したファイル転送または部分的なファイル転送からのリカバリに使用されます。
- If-Range — クライアントがキャッシュ内にそのオブジェクトの一部がすでに含まれている場合に、部分的なオブジェクトを取得できるようにします (条件付き GET)。
- If-Modified-Sins — 要求されたオブジェクトがこのフィールドに指定された時間以降に変更されていない場合、エンティティはサーバーから返されません。HTTP304未変更エラーが発生します。
- 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 チェックなどの高度なセキュリティ保護が有効になっている場合に、データの一時的なキャッシュを許可するために、アプリケーションファイアウォールは、次のロジックを使用して、サーバー応答のキャッシュ制御ヘッダーを追加または変更します。
- サーバーがPragma：no-cacheを送信した場合、アプリケーションファイアウォールは変更を行いません。
- クライアントリクエストがHTTP1.0の場合、アプリケーションファイアウォールはプラグマ：no-cacheを挿入します。
- クライアント要求がHTTP 1.1で、キャッシュ制御：非ストアがある場合、アプリケーションファイアウォールは変更を行いません。
-
クライアント要求がHTTP 1.1であり、サーバー応答にストアまたはキャッシュディレクティブがないキャッシュ制御ヘッダーがある場合、アプリケーションファイアウォールは、任意の変更を行いません。
- クライアント要求が HTTP 1.1 で、サーバー応答にキャッシュ制御ヘッダーがないか、キャッシュ制御ヘッダーにストアまたはキャッシュなしディレクティブがない場合、アプリケーションファイアウォールは次のタスクを完了します。
- キャッシュコントロールを挿入します：最大年齢 = 3、再検証する必要があります、プライベート。
- Inserts X-Cache-Control-orig = Original value of Cache-Control Header.
- 最終更新ヘッダーを削除します。
- ETAGを置き換えます。
- サーバーによって送信された期限切れヘッダーのX-Expire-Orig=元の値を挿入します。
- Expiresヘッダーを変更し、Webページの有効期限を過去に設定して、常に再度取得されるようにします。
- 受け入れ範囲を変更し、noneに設定します。
アプリケーションファイアウォールがStripCommentsのように応答を変更したときに、クライアントブラウザに一時的にキャッシュされたデータを置き換えるには、 X-out/Remove SafeObject、xout、またはクレジットカードまたはURL変換の削除、アプリケーションファイアウォールは次のアクションを実行します。
- クライアントに転送する前に、サーバーから Last-Modified を削除します。
- ETag は、アプリケーションファイアウォールによって決定された値に置き換えます。
Citrix Web App Firewall によって追加されたレスポンスヘッダー
-
Transfer-Encoding: チャンクです。このヘッダーは、応答を送信する前に応答の合計長を知ることなく、クライアントに情報をストリーミングします。このヘッダーは、content-length ヘッダーが削除されるために必要です。 -
Set-Cookie: アプリケーションファイアウォールによって追加されるクッキー。 -
Xet-Cookie: セッションが有効で、応答がキャッシュで期限切れになっていない場合は、キャッシュからサービスを提供でき、セッションはまだ有効であるため、新しい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==" />
<!--NeedCopy-->
HTMLコメントのストリッピング
アプリケーションファイアウォールは、クライアントに送信する前に、応答内のすべてのHTMLコメントを削除するためのオプションも提供します。これは、フォームだけでなく、すべての応答ページにも影響します。アプリケーションファイアウォールは、「<!-」と「->」のコメントタグ。タグは、HTML ソースコードのその場所にコメントが存在したことを示すために残ります。他の HTML または JavaScript タグに埋め込まれたテキストは無視されます。 一部のアプリケーションは、コメントタグ内に JavaScript が誤って埋め込まれていると、正しく動作しないことがあります。Application Firewall によってコメントが削除される前と後のページのソースコードの比較は、削除されたコメントに必要な JavaScript が埋め込まれているかどうかを識別するのに役立ちます。
クレジットカード保護
アプリケーションファイアウォールは、応答のヘッダーと本文を検査し、応答をクライアントに転送する前にクレジットカード番号を削除またはx-outするオプションを提供します。現在、アプリケーションファイアウォールは、次の主要なクレジットカードの保護を提供しています：アメリカン・エキスプレス、ダイナースクラブ、ディスカバー、JCB、マスターカード、およびビザ。x-out アクションは、[ブロック] アクションとは無関係に機能します。
安全な物体保護
クレジットカード番号と同様に、Application Firewall Safe Object セキュリティチェックを使用して、応答内の機密コンテンツを削除または除外することで、他の機密データの漏洩を防ぐこともできます。
クロスサイトスクリプティングはアクションを変換します
トランスフォームでクロスサイトスクリプティングが有効になっている場合、Web AppFirewallはリクエストの "<" into "%26lt;" and ">" into "%26gt;" を変更します。Web App FirewallのcheckRequestHeaders設定が有効になっている場合、Web App Firewallはリクエストヘッダーを検査し、ヘッダーとCookieのこれらの文字も変換します。transform アクションは、サーバーから最初に送信された値をブロックまたは変換しません。Web App Firewallで許可されている、クロスサイトスクリプティング用のデフォルトの属性とタグのセットがあります。拒否されたクロスサイトスクリプティングパターンのデフォルトリストも提供されています。これらは、署名オブジェクトを選択して [管理 ]をクリックすることでカスタマイズできます。 SQL/cross-site GUIでのスクリプトパターンダイアログ。
SQL 特殊文字の変換
アプリケーションファイアウォールには、SQL 特殊文字に対する次のデフォルトの変換ルールがあります。
| ライセンス | 変更後は以下の通り | Transformation |
|---|---|---|
| ’ (single quote that is, %27) | ” | Another single quote |
| \ (backslash that is %5C) | |Another backslash added | |
| ; (semicolon that is %3B) | Dropped |
特殊文字の変換が有効で、checkRequestHeadersがONに設定されている場合、特殊文字の変換はヘッダーとCookieでも行われます。 注：User-Agent、Accept-Encodingなどの一部のリクエストヘッダーにはセミコロンが含まれているため、SQL変換の影響を受ける可能性があります。
EXPECTヘッダーが破損するCitrixWebアプリケーションファイアウォールの動作
- NetScalerがEXPECTヘッダーを含むHTTP要求を受信するたびに、NetScalerはバックエンドサーバーに代わってクライアントにEXPECT：100-continue応答を送信します。
- この動作は、リクエストをサーバーに転送する前に、アプリケーションファイアウォール保護をリクエスト全体に対して実行する必要があるためです。NetScalerはクライアントからリクエスト全体を取得する必要があります。
-
100 continue応答を受信すると、クライアントは要求を完了する要求の残りの部分を送信します。 - その後、NetScalerはすべての保護を実行し、要求をサーバーに転送します。
- NetScalerが完全なリクエストを転送しているため、最初のリクエストに含まれていたEXPECTヘッダーは廃止され、その結果、NetScalerはこのヘッダーを破損して、サーバーに送信します。
- 要求を受信したサーバーは、破損しているヘッダーを無視します。