Application Gateway で HTTP ヘッダーと URL を書き換える

Application Gateway を使用すると、要求と応答で選択したコンテンツを書き直すことができます。 この機能を使用すると、URL、クエリ文字列パラメーター、および要求ヘッダーと応答ヘッダーを変更できます。 また、条件を追加して、特定の条件が満たされたときにのみ URL または指定されたヘッダーが書き換えられます。 これらの条件は、要求と応答の情報に基づいています。

HTTP ヘッダーおよび URL の書き換え機能は、Application Gateway v2 SKU でのみ使用できます。

要求ヘッダーと応答ヘッダー

Application Gateway を使用すると、要求/応答パケットがクライアントとバックエンド プールの間を移動する間に、HTTP 要求および応答ヘッダーを追加、削除、または更新できます。 HTTP ヘッダーを使用すると、クライアントとサーバーは要求または応答で追加情報を渡すことができます。 これらのヘッダーを書き換えることで、次のような重要なタスクを実行できます。

• HSTS や X-XSS-Protection などのセキュリティ関連のヘッダー フィールドの追加
• 機密情報を表示する可能性がある応答ヘッダー フィールドの削除
• X-Forwarded-For ヘッダーからのポート情報の削除

ConnectionヘッダーとUpgradeヘッダーを除き、要求と応答のすべてのヘッダーを書き換えることができます。 また、アプリケーション ゲートウェイを使用してカスタム ヘッダーを作成し、ゲートウェイを経由してルーティングされる要求と応答にヘッダーを追加することもできます。 Azure portal を使用して Application Gateway で要求ヘッダーと応答ヘッダーを書き換える方法については、 こちらを参照してください。

URL パスとクエリ文字列

Application Gateway の URL 書き換え機能を使用すると、次のことができます。

• 要求 URL のホスト名、パス、クエリ文字列を書き換える

• リスナーに対する全要求の URL の書き換え、または設定した 1 つ以上の条件に一致する要求の URL のみの書き換え。 これらの条件は、要求プロパティ (要求ヘッダーとサーバー変数) に基づいています。

• 元の URL または書き換えられた URL に基づく要求のルーティング (バックエンド プールの選択)

Azure portal を使用して Application Gateway で URL を書き換える方法については、 こちらを参照してください。

Application Gateway での書き換えについて

書き換えセットは、ルーティング規則、条件、およびアクションのコレクションです。

• 要求ルーティング規則の関連付け: 書き換え構成は、ルーティング規則を通じてソース リスナーに関連付けられます。 タイプ Basic のルーティング規則を使用すると、書き換え構成はそのリスナーに関連付け、グローバル書き換えとして機能します。 パスベースのルーティング規則を使用する場合は、URL パス マップに従って書き換え構成を定義します。 後者の場合、サイトの特定のパス領域にのみ適用されます。 書き換えセットは複数のルーティング規則に適用できますが、ルーティング規則に関連付けられる書き換えは 1 つだけです。

• 書き換え条件: この構成は省略可能です。 定義した条件に基づいて、Application Gateway は HTTP(S) 要求と応答の内容を評価します。 後続の "書き換えアクション" は、HTTP(S) 要求または応答がこの条件と一致する場合に発生します。 複数の条件を 1 つのアクションと関連付けた場合は、すべての条件が満たされた場合にのみアクションが発生します。 つまり、論理 AND 演算です。 書き換え条件を使い、HTTP(S) の要求と応答の内容を評価できます。 このオプションの構成では、1 つ以上の条件が満たされた際にのみ書き換えを行えます。 アプリケーション ゲートウェイは、次の 3 種類の変数を使用して、要求と応答のコンテンツを評価します。

  次の種類を選択して条件を検索できます。

  • HTTP ヘッダー (要求と応答)
  • サポートされているサーバー変数

  条件を使用すると、指定したヘッダーまたは変数が存在するかどうかを、テキストまたは正規表現パターンを使用して値を照合して評価できます。 高度な書き換え構成の場合、ヘッダーまたはサーバー変数の値を取り込んで、後で書き換えアクションで使用することもできます。 パターンとキャプチャの詳細を確認します。

• 書き換えアクション: 書き換えアクション セットを使用すると、ヘッダー (要求または応答) または URL コンポーネントを書き換えることができます。

  アクションには、次の値の型またはそれらの組み合わせを含めることができます。

  • テキスト。
  • 要求ヘッダーの値 - キャプチャされた要求ヘッダーの値を使用するには、構文を {http_req_headerName}として指定します。
  • 応答ヘッダーの値 - 前の条件からキャプチャされた応答ヘッダーの値を使用するには、構文を {http_resp_headerName}として指定します。 リライト アクション ブロックでは、Set-Cookie ヘッダーの "Header Value Matcher" フィールドもサポートされています。 この省略可能なフィールドを使用すると、同じ名前の複数の Set-Cookie ヘッダーが存在する場合に、特定のヘッダーの値を照合してキャプチャできます。 その特定のクッキーのキャプチャされた値を操作するために、{capt_header_value_matcher} を使用できます。 キャプチャの詳細については、「 アクション セット」を参照してください。
  • サーバー変数 - サーバー変数を使用するには、構文を {var_serverVariable} として指定します。 サポートされているサーバー変数の一覧。

アクションを使用して URL を書き換えると、次の操作がサポートされます。

• URL パス: パスとして設定する新しい値。
• URL クエリ文字列: クエリ文字列の書き換え先になる新しい値。
• パス マップを再評価する: 書き換え後に URL パス マップを再評価する必要があるかどうかを指定します。 このオプションをオンにしない場合は、元の URL パスが URL パス マップ内のパス パターンと一致するために使用されます。 このオプションを true に設定すると、URL パス マップが再評価され、書き換えられたパスとの一致が確認されます。 このスイッチを有効にすると、書き換え後に要求を別のバックエンド プールにルーティングする際に役立ちます。

パターン マッチングと取り込み

Application Gateway では、条件とアクションでのパターン マッチングとキャプチャがサポートされています。 [アクション] では、特定のヘッダーに対してのみパターン マッチングとキャプチャがサポートされます。

パターン マッチング

Application Gateway では、パターン マッチングに正規表現が使用されます。 パターン マッチング構文を記述するときは、正規表現 2 (RE2) 互換の式を使用します。

条件とアクションの両方でパターン マッチングを使用できます。

• 条件: ヘッダー変数またはサーバー変数の値を照合するには、この設定を使用します。 "条件" のパターンと一致するには、"pattern" プロパティを使用します。
• アクション: アクション セットのパターン マッチングは、応答ヘッダー Set-Cookieに対してのみ使用できます。 アクションの Set-Cookie のパターンと一致するには、 HeaderValueMatcher プロパティを使用します。 キャプチャした場合、その値は {capt_header_value_matcher}として使用できます。 複数の Set-Cookie ヘッダーが存在する可能性があるため、ここでパターン マッチングを行うと、特定の Cookie を検索できます。 たとえば、特定のバージョンのユーザー エージェントでは、set-cookieのcookie2応答ヘッダーを max-age=3600 (1 時間) で書き換える必要があります。 この場合、以下を使用できます
  • 条件 - 種類: 要求ヘッダー、ヘッダー名: user-agent、一致させるパターン: *2.0
  • アクション - リライトタイプ: レスポンスヘッダー、アクションタイプ: Set、ヘッダー名: Set-Cookie、ヘッダー値マッチャー: cookie2=(.*)、ヘッダー値: cookie2={capt_header_value_matcher_1};Max-Age=3600

取り込みの構文

後で使用するために、パターンを使用して部分文字列をキャプチャできます。 正規表現定義内のサブパターンをかっこで囲みます。 かっこの最初のペアによってその部分文字列が 1 に、2 番目のペアによって 2 に格納されます (以下同様)。 括弧を好きなだけ使用できます。 Perl は、これらのキャプチャされた文字列を表すために、より多くの番号付き変数を定義します。 この Perl プログラミング ガイダンスには、いくつかの例があります。

• (\d)(\d) # 2 桁を照合し、それらをグループ 1 と 2 にキャプチャします
• (\d+) # 1 桁以上の数字を照合し、すべてをグループ 1 にキャプチャします
• (\d)+ # 1 桁を 1 回以上照合し、最後の数字をグループ 1 にキャプチャします

取り込みが完了したら、次の形式を使用してアクション セット値で使用できます。

• 要求ヘッダーのキャプチャの場合は、{http_req_headerName_groupNumber} を使用する必要があります。 たとえば、{http_req_User-Agent_1} または {http_req_User-Agent_2} です
• 応答ヘッダーのキャプチャの場合は、{http_resp_headerName_groupNumber} を使用する必要があります。 たとえば、{http_resp_Location_1} または {http_resp_Location_2} です。 一方、"HeaderValueMatcher" プロパティを使用して取り込まれた応答ヘッダー Set-Cookie の場合は、{capt_header_value_matcher_groupNumber} を使用する必要があります。 たとえば、{capt_header_value_matcher_1} または {capt_header_value_matcher_2} です。
• サーバー変数の場合は、{var_serverVariableName_groupNumber} を使用する必要があります。 たとえば、{var_uri_path_1} または {var_uri_path_2} です

サーバー変数

Application Gateway では、サーバー変数を使用して、サーバー、クライアントとの接続、およびその接続での現在の要求に関する情報が格納されます。 格納される情報には、クライアントの IP アドレスや Web ブラウザーの種類などがあります。 サーバー変数は、たとえば新しいページが読み込まるときや、フォームが投稿されるときに動的に変化します。 これらの変数を使用して、書き換え条件を評価し、ヘッダーを書き換えることができます。 サーバー変数の値を使ってヘッダーを書き換えるには、構文 {var_serverVariableName} でこれらの変数を指定する必要があります。

アプリケーション ゲートウェイでは、次のサーバー変数がサポートされています。

相互認証サーバー変数

Application Gateway は、相互認証のシナリオに対して次のサーバー変数をサポートしています。 他のサーバー変数と同様に、これらのサーバー変数を使用します。

ヘッダーの書き換えの一般的なシナリオ

X-Forwarded-For ヘッダーからポート情報を削除する

Application Gateway では、要求をバックエンドに転送する前に、すべての要求に X-Forwarded-For ヘッダーが挿入されます。 このヘッダーは、IP ポート のコンマ区切りリストです。 バックエンド サーバーでヘッダーに IP アドレスが含まれることだけが必要なシナリオがあるとします。 ヘッダーの書き換えを使用して X-Forwarded-For ヘッダーからポート情報を削除できます。 これを行う 1 つの方法は、ヘッダーを add_x_forwarded_for_proxy サーバー変数に設定することです。 または、client_ip 変数を使用することもできます。

リダイレクト URL を変更する

リダイレクト URL の変更は、特定の状況で役立ちます。 たとえば、最初は "/blog" のようなパスにクライアントをリダイレクトしますが、コンテンツ構造の変更により、クライアントを "/updates" に送信したいと考える場合があります。

アプリ サービスでは、リダイレクト応答を送信するとき、その応答の場所ヘッダーで、アプリケーション ゲートウェイから受信した要求のものと同じホスト名が使用されます。 そのためクライアントでは、アプリケーション ゲートウェイ (contoso.azurewebsites.net/path2) 経由ではなく、contoso.com/path2 に直接要求を行います。 アプリケーション ゲートウェイをバイパスすることは望ましくありません。

この問題は、場所ヘッダーのホスト名をアプリケーション ゲートウェイのドメイン名に設定することで解決できます。

ホスト名を置換する手順を次に示します。

1. 応答の location ヘッダーに azurewebsites.net が含まれているかどうかを確認する条件を使用して書き換えルールを作成します。 パターン '(https?):// を入力します。azurewebsites.net(.).

2. アプリケーション ゲートウェイのホスト名を含むように、場所ヘッダーを書き換えるにアクションを実行します。 ヘッダー値として「 {http_resp_Location_1}://contoso.com{http_resp_Location_2} 」と入力します。 または、サーバー変数 host を使用して、元の要求と一致するようにホスト名を設定することもできます。

   

脆弱性を防ぐための HTTP セキュリティ ヘッダーを実装する

アプリケーションの応答で必要なヘッダーを実装することにより、いくつかのセキュリティの脆弱性を修正できます。 たとえば、X-XSS-Protection、Strict-Transport-Security、Content-Security-Policy などのセキュリティ ヘッダーです。 Application Gateway を使用して、すべての応答にこれらのヘッダーを設定できます。

不要なヘッダーを削除する

HTTP 応答から、機密情報を明らかにするヘッダーを削除することができます。 たとえば、バックエンド サーバー名、オペレーティング システム、ライブラリの詳細などの情報を削除できます。 アプリケーション ゲートウェイを使用して、これらのヘッダーを削除できます。

ホスト ヘッダーを削除する書き換えルールを作成することはできません。 アクションの種類が削除に、ヘッダーがホストにそれぞれ設定されている書き換え規則を作成しようとすると、エラーが発生します。

ヘッダーの有無を確認する

HTTP 要求または応答ヘッダーを評価し、ヘッダーまたはサーバー変数の有無を確認できます。 この評価は、特定のヘッダーが存在する場合にのみヘッダーの書き換えを実行する場合に役立ちます。

URL の書き換えの一般的なシナリオ

パラメーター ベースのパスの選択

要求内のヘッダー、URL の一部、またはクエリ文字列の値に基づいてバックエンド プールを選択するシナリオを実現するには、URL 書き換え機能とパスベースのルーティングの組み合わせを使用します。

特定のパラメーター (クエリ文字列、ヘッダーなど) をチェックし、URL パスを変更するアクションを実行する条件を使用して書き換えセットを作成します ( パス マップの再評価 が有効になっていることを確認します)。 書き換えセットをパス ベースの規則に関連付けます。 パス ベースの規則には、書き換えセットで指定されているのと同じ URL パスと対応するバックエンド プールが含まれている必要があります。

したがって、書き換えセットを使用すると、特定のパラメーターを確認して新しいパスを割り当てることができます。パス ベースの規則を使用すると、それらのパスにバックエンド プールを割り当てることができます。 "パス マップの再評価" が有効になっている限り、書き換えセットで指定されたパスに基づいてトラフィック がルーティングされます。

クエリ文字列を使用したユース ケースの例については、「ポータルでのパラメーター ベースのパス選択を使用してトラフィックをルーティングする」を参照してください。

URL に基づいてクエリ文字列パラメーターを書き換える

ユーザーが表示できるリンクがシンプルで読みやすいが、バックエンド サーバーで適切なコンテンツを表示するためにクエリ文字列パラメーターが必要なショッピング Web サイトのシナリオを考えてみましょう。

その場合、Application Gateway は URL からパラメーターをキャプチャし、URL 内のこれらのパラメーターからクエリ文字列のキーと値のペアを追加できます。 たとえば、ユーザーがhttps://www.contoso.com/fashion/shirtsにhttps://www.contoso.com/buy.aspx?category=fashion&product=shirts書き換える場合は、次の URL 書き換え構成を使用してこの目標を達成できます。

条件 - サーバー変数 uri_path パターンと等しい場合 /(.+)/(.+)

アクション - URL パスを buy.aspx に設定し、クエリ文字列を category={var_uri_path_1}&product={var_uri_path_2} に設定します

前述のシナリオを実現するための詳細なガイドについては、「 Azure portal を使用した Application Gateway での URL の書き換え」を参照してください。

書き込み構成に関する一般的な落とし穴

• 基本的な要求ルーティング規則に対して "パス マップの再評価" を有効にすることはできません。 この制限により、基本的なルーティング規則の無限評価ループが防止されます。

• パスベースのルーティング規則の場合は、少なくとも 1 つの条件付き書き換え規則または 1 つの書き換え規則が必要です。"パス マップの再評価" が有効になっていません。 この要件により、パスベースのルーティング規則の無限評価ループが回避されます。

• クライアント入力に基づいてループが動的に作成された場合、受信要求は 500 エラー コードで終了します。 Application Gateway は、このシナリオで低下することなく、引き続き他の要求を処理します。

Web アプリケーション ファイアウォール (WAF_v2 SKU) で URL 書き換えまたはホスト ヘッダー書き換えを使用する

URL 書き換えまたはホスト ヘッダー書き換えを構成すると、要求ヘッダーまたは URL パラメーターへの変更後 (書き換え後) に、WAF 評価が行われます。 Application Gateway で URL 書き換えまたはホスト ヘッダー書き換え構成を削除すると、ヘッダーの書き換え (事前書き換え) の前に WAF の評価が行われます。 この順序により、バックエンド プールが受け取る最終的な要求に WAF 規則が適用されます。

たとえば、ヘッダー "Accept" : "text/html" の次のヘッダー書き換え規則があるとします。ヘッダー "Accept" の値が "text/html" と等しい場合は、値を "image/png" に書き換える必要があります。

ヘッダー書き換えのみが構成されている場合、WAF の評価は "Accept" : "text/html"で行われます。 ただし、URL 書き換えまたはホスト ヘッダーの書き換えを構成すると、WAF の評価は "Accept" : "image/png"で行われます。

URL の書き換えと URL のリダイレクト

URL 書き換えの場合、Application Gateway は要求をバックエンドに送信する前に URL を書き換える。 この操作では、ユーザーに対して変更が非表示になるため、ブラウザーに表示される内容は変更されません。

URL のリダイレクトの場合、Application Gateway は新しい URL を使用してリダイレクトの応答をクライアントに送信します。 この応答では、クライアントはリダイレクトで指定された新しい URL に要求を再送信する必要があります。 ブラウザーでユーザーに表示される URL は、新しい URL に更新されます。

制限事項

• アプリケーション ゲートウェイが要求をリダイレクトするように構成されているとき、またはカスタム エラー ページを表示するように構成されているときは、書き換えはサポートされません。
• 要求ヘッダー名には、英数字とハイフンを含めることができます。 他の文字を含むヘッダー名は、要求がバックエンド ターゲットに送信されるときに破棄されます。
• 応答ヘッダー名には、任意の英数字と、RFC 7230 で定義されている特定の記号を含めることができます。
• X-Original-Host、Connection、およびupgradeヘッダーを書き換えることはできません。
• Application Gateway から直接生成された 4xx 応答と 5xx 応答では、書き換えはサポートされていません。

次のステップ

• Azure portal を使用して Application Gateway で HTTP ヘッダーを書き換える方法
• Azure portal を使用して Application Gateway で URL を書き換える方法