Переопределение HTTP-заголовков и URL-адресов с помощью Шлюза приложений Azure

Шлюз приложений позволяет переписать выбранное содержимое в запросах и ответах. С помощью этой функции можно перевести URL-адреса, параметры строки запроса и изменить заголовки запросов и ответов. Вы также можете добавить условия, чтобы убедиться, что URL-адрес или указанные заголовки перезаписываются только в случае выполнения определенных условий. Эти условия основываются на сведениях о запросе и ответе.

Функции перезаписи заголовков HTTP и URL-адресов доступны только для SKU Шлюз приложений версии 2.

Заголовки запросов и ответов

Шлюз приложений позволяет добавлять, удалять или обновлять заголовки HTTP-запросов и ответов при перемещении пакетов запросов и ответов между клиентскими и внутренними пулами. Заголовки HTTP позволяют клиенту и серверу передавать дополнительные сведения с запросом или ответом. Перезаписав эти заголовки, можно выполнить важные задачи, включая:

• Добавление полей заголовков, связанных с безопасностью, таких как HSTS и X-XSS-Protection
• Удаление полей заголовка ответа, которые могут показать конфиденциальную информацию
• Удаление сведений о порту из заголовков X-Forwarded-For

Вы можете переписать все заголовки в запросах и ответах, за исключением Connection заголовков и Upgrade заголовков. Вы также можете использовать шлюз приложений для создания пользовательских заголовков и добавления их в запросы и ответы, которые направляются через него. Сведения о перезаписи заголовков запросов и ответов с помощью шлюза приложений с помощью портала Azure см. здесь.

URL-путь и строка запроса

Возможность повторного создания URL-адресов в шлюзе приложений позволяет:

• Переопределите имя узла, путь и строку запроса URL-адреса запроса

• Выберите перезаписать URL-адрес всех запросов прослушивателя или только те запросы, которые соответствуют одному или нескольким заданным условиям. Эти условия основаны на свойствах запроса (переменные заголовка запроса и сервера).

• Выбрать маршрутизацию запроса (с выбором внутреннего пула) на основе исходного URL-адреса или перезаписанного URL-адреса

Сведения о перезаписи URL-адреса с помощью шлюза приложений с помощью портала Azure см. здесь.

Понимание перезаписей в шлюзе приложений

Набор правил редактирования — это коллекция правила маршрутизации, условия и действия.

• Сопоставление правил маршрутизации запросов: Конфигурация перезаписи связывается с прослушивателем источника с помощью правила маршрутизации. При использовании правила маршрутизации типа Basic конфигурация перезаписи связывается с прослушивателем и работает как глобальная перезапись. При использовании правила маршрутизации на основе пути вы определяете конфигурацию перезаписи в соответствии с схемой пути URL-адреса. В последнем случае он применяется только к определенной области пути сайта. Вы можете применить набор перезаписи к нескольким правилам маршрутизации, но правило маршрутизации может иметь только одну перезапись, связанную с ним.

• Условие переопределения: Эта конфигурация является необязательной. На основе заданных условий шлюз приложений оценивает содержимое запросов и ответов HTTP(S). Последующие действия перезаписи возникают, если запрос ИЛИ ответ HTTP(S) соответствует этому условию. При связывании более одного условия с действием оно выполняется только при соблюдении всех условий. Другими словами, это логическая операция AND. Для оценки содержимого запросов и ответов HTTP(S) можно использовать условия перезаписи. Эта необязательная конфигурация позволяет выполнять перезапись только при выполнении одного или нескольких условий. Шлюз приложений использует представленные ниже типы переменных для вычисления содержимого запросов и ответов:

  Для поиска условия можно выбрать следующие типы:

  • Заголовок HTTP (запрос и ответ)
  • Поддерживаемые переменные сервера

  Условие позволяет оценить, существует ли указанный заголовок или переменная путем сопоставления значений с помощью текста или шаблона Regex. Для расширенных конфигураций перезаписи можно также записать значение переменной заголовка или сервера для последующего использования в разделе "Действие перезаписи". Узнайте больше о паттерне и захвате.

• Действие перезаписи: Набор действий перезаписи позволяет переписать заголовки (запрос или ответ) или компоненты URL-адреса.

  Действие может иметь следующие типы значений или их сочетания:

  • Текст.
  • Значение заголовка запроса. Чтобы использовать значение записанного заголовка запроса, укажите синтаксис как {http_req_headerName}.
  • Значение заголовка ответа. Чтобы использовать значение заголовка записанного ответа из предыдущего условия, укажите синтаксис как {http_resp_headerName}. Блок действия перезаписи также поддерживает поле "Сопоставление значений заголовка" для заголовка Set-Cookie. Это необязательное поле позволяет сопоставлять и записывать значение определенного заголовка при наличии нескольких Set-Cookie заголовков с одинаковым именем. Для управления захваченным значением этого файла cookie можно использовать {capt_header_value_matcher}. Узнайте больше о захвате в наборе действий.
  • Переменная сервера. Чтобы использовать переменную сервера, укажите синтаксис как {var_serverVariable}. Список поддерживаемых переменных сервера.

Примечание.

Использование поля "Сопоставление значений заголовка" {capt_header_value_matcher} в настоящее время не поддерживается через портал. Поэтому при использовании этого поля необходимо использовать метод, отличный от портального, для любых операций PUT.

При использовании действия для перезаписи URL-адреса поддерживаются следующие операции:

• URL-путь: новое значение, заданное в качестве пути.
• Строка запроса URL: новое значение, в которое должна быть перезаписана строка запроса.
• Повторное вычисление карты пути. Укажите, должна ли карта пути URL-адреса повторно оцениваться после перезаписи. Если не выбрать этот параметр, оригинальный путь URL используется для сопоставления шаблона пути в карте путей URL. Если для этого параметра задано значение true, схема пути URL будет пересмотрена, чтобы проверить соответствие с переписанным путем. Включение этого параметра помогает в маршрутизации запроса к другому внутреннему пулу после перезаписи.

Сопоставление шаблонов и запись

Шлюз приложений поддерживает сопоставление шаблонов и захват в разделе "Условие" и "Действие". Под "Действием" осуществляется поддержка сопоставления шаблонов и записи только для определенного заголовка.

Сопоставление шаблонов

Шлюз приложений использует регулярные выражения для сопоставления шаблонов. При написании синтаксиса сопоставления шаблонов используйте совместимые с RE2 регулярные выражения.

Вы можете использовать сопоставление шаблонов как в условии, так и в действии.

• Условие. Используйте этот параметр для сопоставления значений для переменной заголовка или сервера. Чтобы соответствовать шаблону в разделе "Условия", используйте свойство pattern.
• Действие: сопоставление шаблонов в группе действий доступно только для заголовка Set-Cookieответа. Чтобы сопоставить шаблон для Set-Cookie действия, используйте HeaderValueMatcher свойство. Если он записан, его значение можно использовать как {capt_header_value_matcher}. Так как здесь может быть несколько Set-Cookie заголовков, сопоставление шаблонов позволяет искать определенный файл cookie. Например, для определенной версии пользовательского агента вы хотите переписать заголовок ответа set-cookie для cookie2, используя max-age=3600 (один час). В этом случае можно использовать
  • Условие — тип: заголовок запроса, имя заголовка: user-agent, шаблон для сопоставления: *2.0
  • Действие — переопределение типа: заголовок ответа, тип действия: Set, Имя заголовка: Set-Cookie, Значение заголовка: cookie2=(.*), значение заголовка: cookie2={capt_header_value_matcher_1};Max-Age=3600

Примечание.

Если вы используете Application Gateway Web Application Firewall (WAF) с набором основных правил 3.1 или более ранней версии, при использовании регулярных выражений, совместимых с Perl (PCRE), при выполнении утверждений lookahead и lookbehind (отрицательных или положительных) вы можете столкнуться с проблемами.

Синтаксис для записи

Вы можете использовать шаблоны для записи подстроки для последующего использования. Поместите круглые скобки вокруг подшаблоны в определении regex. Первая пара скобок хранит свою подстроку в 1, вторую пару в 2 и т. д. Вы можете использовать столько круглых скобок, сколько вам нравится. Perl определяет более нумерованные переменные для представления этих захваченных строк. В этом руководстве по программированию Perl можно найти некоторые примеры.

• (\d)(\d) # Сопоставление двух цифр, захват их в группы 1 и 2
• (\d+) # Сопоставление одной или нескольких цифр, захватив их в группу 1
• (\d)+ # Сопоставление цифры один или несколько раз, захватив последний в группу 1

После записи их можно использовать в значении набора действий с помощью следующего формата:

• Для захвата заголовка запроса необходимо использовать {http_req_headerName_groupNumber}. Например, {http_req_User-Agent_1} или {http_req_User-Agent_2}
• Для захвата заголовка ответа необходимо использовать {http_req_headerName_groupNumber}. Например, {http_resp_Location_1} или {http_resp_Location_2}. В то время как для заголовка ответа Set-Cookie, записанного с помощью свойства HeaderValueMatcher, необходимо использовать {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}

Примечание.

• Использование / в качестве префикса и суффикса в шаблоне не должно указываться для соответствия значениям. Например, (\d)(\d) будет соответствовать двум цифрам. /(\d)(\d)/ не соответствует двум цифрам.
• Случай переменной условия должен соответствовать регистру переменной записи. Например, если моя переменная условия — User-Agent, то моя переменная захвата должна быть для User-Agent (то есть {http_req_User-Agent_2}). Если переменная условия задана как пользовательский агент, переменная для сбора данных должна быть для пользовательского агента (то есть {http_req_user-agent_2}).
• Если вы хотите использовать полное значение, не следует упоминать число. Просто используйте формат {http_req_headerName} и т. д. без groupNumber.

Переменные сервера

Шлюз приложений использует переменные сервера для хранения полезной информации о сервере, подключении к клиенту и текущем запросе к соединению. Примеры хранимых сведений включают IP-адрес клиента и тип веб-браузера. Переменные сервера изменяются динамически, например при загрузке новой страницы или при публикации формы. Эти переменные можно использовать для вычисления условий перезаписи и перезаписи заголовков. Чтобы использовать значение переменных сервера для перезаписи заголовков, необходимо указать эти переменные в синтаксисе {var_serverVariableName}

Шлюз приложений поддерживает перечисленные ниже переменные сервера:

Имя переменной	Описание
add_x_forwarded_for_proxy	Поле заголовка X-Forwarded-For в запросе клиента с переменной client_ip (см. описание далее в этой таблице) добавляется к ней в формате IP1, IP2, IP3 и т. д. Если в заголовке запроса клиента нет поля X-Forwarded-For, значение переменной add_x_forwarded_for_proxy будет равно значению переменной $client_ip. Эта переменная полезна, если вы хотите перезаписать заголовок X-Forwarded-For, заданный Шлюз приложений, чтобы заголовок содержал только IP-адрес без сведений о порту.
поддерживаемые шифры	Возвращает список шифров, поддерживаемых клиентом.
используемые шифры	Возвращает строку шифров, которая используется для установленного соединения TLS.
client_ip (IP-адрес клиента)	IP-адрес клиента, от которого шлюз приложений получил запрос. Если перед шлюзом приложений и источником клиента есть обратный прокси-сервер, client_ip возвращает IP-адрес обратного прокси-сервера.
порт клиента	Порт клиента.
client_tcp_rtt	Сведения о TCP-подключении клиента. Доступно для систем, поддерживающих дополнительный сокет TCP_INFO.
клиент_пользователь	При использовании проверки подлинности HTTP эта переменная будет содержать имя пользователя, передаваемое для проверки подлинности.
host	В следующем порядке значимости: имя узла из строки запроса, имя узла из поля "Host" в заголовке запроса или имя сервера, соответствующее запросу. Пример. В запросе http://contoso.com:8080/article.aspx?id=123&title=fabrikamзначение узла равно contoso.com
cookie_имя	Имя файла cookie.
HTTP-метод	Метод, используемый для выполнения запроса URL-адреса. Например, GET или POST.
HTTP-статус	Статус сеанса. Например, 200, 400 или 403.
http_version	Протокол запроса. Обычно это бывает HTTP/1.0, HTTP/1.1 или HTTP/2.0.
строка запроса	Список пар переменных и значений, следующий за ? в запрашиваемом URL-адресе. Пример. В запросе http://contoso.com:8080/article.aspx?id=123&title=fabrikamзначение query_string id=123&title=fabrikam
полученные байты	Длина запроса (включая строку запроса, заголовок и текст запроса).
request_query	Аргументы в строке запроса.
схема_запроса	Схема запроса: HTTP или HTTPS.
URI запроса	Полный исходный код URI запроса (с аргументами). Пример: в запросе http://contoso.com:8080/article.aspx?id=123&title=fabrikam*значение request_uri /article.aspx?id=123&title=fabrikam
отправленные_байты	Количество отправленных клиенту байтов.
порт сервера	Порт сервера, принявшего запрос.
ssl_протокол_соединения	Протокол установленного подключения TLS.
ssl_enabled	Значение "Включено", если подключение работает в режиме TLS. В противном случае — пустая строка.
путь URI	Определяет конкретный ресурс на узле, к которому требуется доступ из веб-клиента. Переменная ссылается на исходный путь URL-адреса перед любой манипуляцией. Это часть URI запроса без аргументов. Например, в запросе http://contoso.com:8080/article.aspx?id=123&title=fabrikamзначение uri_path./article.aspx

Переменные сервера взаимной проверки подлинности

Шлюз приложений поддерживает следующие переменные сервера для взаимной проверки подлинности. Используйте эти переменные сервера, как и другие переменные сервера.

Имя переменной	Описание
сертификат клиента	Сертификат клиента для установленного SSL-соединения в формате PEM.
дата окончания действия клиентского сертификата	Дата окончания действия сертификата клиента.
отпечаток_сертификата_клиента	Отпечаток SHA1 сертификата клиента для установленного SSL-соединения.
выдавший_сертификат_клиента	Значение строки "issuer DN" сертификата клиента для установленного SSL-соединения.
серийный номер клиентского сертификата	Серийный номер сертификата клиента для установленного SSL-соединения.
дата_начала_сертификата_клиента	Дата начала действия сертификата клиента.
предмет сертификата клиента	Значение строки "subject DN" сертификата клиента для установленного SSL-соединения.
проверка клиентского сертификата	Результат проверки сертификата клиента: SUCCESS, FAILED:<reason> или NONE , если сертификат отсутствует.

Распространенные сценарии для перезаписи заголовков

Удаление информации о портах из заголовков X-Forwarded-For

Шлюз приложений вставляет заголовок X-Forwarded-For во все запросы перед их перенаправлением в серверную часть. Этот заголовок представляет собой разделенный запятыми список IP-портов. Могут возникнуть сценарии, в которых серверные серверы должны содержать только заголовки, чтобы содержать IP-адреса. Можно использовать перезапись заголовка для удаления сведений о портах из заголовка X-Forwarded-For. Один из способов сделать это — задать в качестве заголовка переменную сервера add_x_forwarded_for_proxy. Также можно использовать переменную client_ip:

Изменение URL-адреса перенаправления

Изменение URL-адреса перенаправления может оказаться полезным при определенных обстоятельствах. Например, вы можете первоначально перенаправлять клиентов на такой путь, как "/blog", но теперь хотите перенаправить их в "/updates" в связи с изменением структуры контента.

Предупреждение

При настройке Application Gateway для переопределения имени хоста для использования в серверной части, может потребоваться изменить URL-адрес перенаправления. В этой конфигурации серверная часть видит другое имя узла, чем браузер. Перенаправление не использует правильное имя узла. Такую конфигурацию использовать не рекомендуется.

Дополнительные сведения об ограничениях и последствиях такой конфигурации см. в разделе Сохранение исходного имени узла HTTP между обратным прокси-сервером и серверным веб-приложением. Рекомендуемую настройку службы приложений см. в разделе "Личный домен (рекомендуется)" в разделе "Настройка службы приложений с помощью шлюза приложений". Переписывание заголовка Location в ответе, как описано в следующем примере, следует считать обходным решением и не устраняет первопричину.

При отправке ответа перенаправления служба приложений использует то же имя узла в заголовке расположения своего ответа, что и в запросе, полученном от шлюза приложений. Таким образом, клиент выполняет запрос непосредственно contoso.azurewebsites.net/path2 , чтобы не проходить через шлюз приложений (contoso.com/path2). Обход шлюза приложений нежелателен.

Эту проблему можно устранить, установив параметр имени узла в заголовке расположения в значение доменного имени шлюза приложений.

Ниже приведены действия по замене имени узла.

1. Создайте правило перезаписи с условием, которое проверяет, содержит ли заголовок расположения в ответе 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. Задать эти заголовки для всех ответов можно с помощью шлюза приложений.

Удаление ненужных заголовков

Вам может понадобиться удалить заголовки, которые раскрывают конфиденциальную информацию из HTTP-ответа. Например, может потребоваться удалить такие сведения, как имя внутреннего сервера, операционная система или сведения о библиотеке. Для удаления этих заголовков можно использовать шлюз приложений:

Невозможно создать правило перезаписи, чтобы удалить заголовок узла. Если вы пытаетесь создать правило перезаписи с типом действия, заданным для удаления, и заголовок, заданный для узла, это приведет к ошибке.

Проверка наличия заголовка

Вы можете оценить HTTP-запрос или заголовок ответа на наличие заголовка или переменной сервера. Эта оценка будет полезна, если требуется выполнить перезапись заголовка только при наличии определенного заголовка.

Распространенные сценарии для переопределения URL-адресов

Выбор пути на основе параметров

Чтобы выполнить сценарии, в которых необходимо выбрать внутренний пул на основе значения заголовка, части URL-адреса или строки запроса в запросе, используйте сочетание возможностей переопределения URL-адресов и маршрутизации на основе пути.

Создайте набор перезаписи с условием, который проверяет наличие определенного параметра (строка запроса, заголовок и т. д.), а затем выполняет действие, в котором изменяется URL-путь (убедитесь, что включена карта пути повторного вычисления ). Свяжите набор правил перезаписи с правилом на основе пути. Правило на основе пути должно содержать те же URL-пути, которые указаны в наборе перезаписи и соответствующем серверном пуле.

Таким образом, набор перезаписи позволяет проверить наличие определенного параметра и назначить ему новый путь, а правило, основанное на пути, позволяет назначать серверные пулы этим путям. Если включена функция "Переоценка пути", маршруты трафика основаны на пути, указанном в наборе перезаписи.

Пример использования с помощью строк запроса см. в разделе "Маршрут трафика" с помощью выбора пути на основе параметров на портале.

Перепись параметры строки запроса на основе URL-адреса

Рассмотрим сценарий веб-сайта покупок, где видимая пользователем ссылка является простой и удобочитаемой, но серверный сервер нуждается в параметрах строки запроса для отображения правильного содержимого.

В этом случае Шлюз приложений может записывать параметры из 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}

Пошаговое руководство по достижению сценария, описанного ранее, см. в статье "Перезапись URL-адреса с помощью шлюза приложений" с помощью портала Azure.

Распространенные ошибки конфигурации перезаписи

• Невозможно включить "Повторное вычисление схемы пути" для основных правил маршрутизации запросов. Это ограничение предотвращает бесконечный цикл оценки для базового правила маршрутизации.

• Для правил маршрутизации на основе пути требуется по крайней мере одно условное правило перезаписи или одно правило перезаписи без включенного параметра 'повторной оценки карты маршрутов'. Это требование предотвращает бесконечный цикл оценки для правила маршрутизации на основе пути.

• Если цикл создается динамически на основе входных данных клиента, входящие запросы завершаются кодом ошибки 500. Шлюз приложений продолжает обслуживать другие запросы без каких-либо ухудшений в этом сценарии.

Использование переопределения URL-адреса или перезаписи заголовка узла с брандмауэром веб-приложения (WAF_v2 SKU)

При настройке перезаписи URL-адресов или перезаписи заголовка узла оценка WAF происходит после изменения параметров заголовка запроса или URL-адреса (после перезаписи). При удалении конфигурации перезаписи URL или перезаписи заголовка хоста в шлюзе приложений оценка WAF выполняется до перезаписи заголовка (предварительная перезапись). Этот порядок гарантирует, что правила WAF применяются к окончательному запросу, который получает пул серверов обработки.

Например, предположим, что у вас есть следующее правило переопределения заголовка для заголовка "Accept" : "text/html" — если значение заголовка "Accept" равно "text/html", то переопределите значение на "image/png".

При настройке только изменения заголовков оценка WAF выполняется на "Accept" : "text/html". Но при настройке перезаписи URL-адресов или перезаписи заголовка узла, оценка WAF выполняется на "Accept" : "image/png".

Сравнение переопределения URL-адреса и перенаправления URL-адреса

Для перезаписи URL-адреса шлюз приложений перезаписывает URL-адрес перед отправкой запроса в серверную часть. Это действие не изменяет то, что пользователи видят в браузере, так как изменения скрыты от пользователя.

Для перенаправления URL-адресов Шлюз приложений отправляет клиенту ответ перенаправления с новым URL-адресом. Этот ответ требует от клиента повторно отправить запрос на новый URL-адрес, предоставленный в перенаправлении. URL-адрес, который пользователь видит в браузере, обновляет новый URL-адрес.

Ограничения

• Перезаписи не поддерживаются, если шлюз приложений настроен для перенаправления запросов или отображения пользовательской страницы ошибок.
• Имена заголовков запросов могут содержать буквенно-цифровые символы и дефисы. Имена заголовков, содержащие другие символы, удаляются при отправке запроса на серверный целевой объект.
• Имена заголовков ответа могут содержать любые буквенно-цифровые символы и определенные символы, как определено в RFC 7230.
• Вы не можете переписать X-Original-Hostи Connectionupgrade заголовки.
• Перезаписи не поддерживаются для ответов 4xx и 5xx, созданных непосредственно из шлюза приложений.

Следующие шаги

• Узнайте больше о том, как переопределить HTTP-заголовок с помощью шлюза приложений, используя портал Azure
• Узнайте больше о том, как переопределить URL-адрес с помощью шлюза приложений, используя портал Azure