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

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

Функции перезаписи заголовков HTTP и URL доступны только для SKU Application Gateway v2.

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

Шлюз приложений позволяет добавлять, удалять или обновлять заголовки 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. Для расширенных конфигураций перезаписи можно также записать значение переменной заголовка или сервера для последующего использования в разделе "Действие перезаписи". Узнайте больше о паттерне и захвате.

Действие перезаписи

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

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

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

При использовании действия для перезаписи 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 Брандмауэр веб-приложений (WAF) с набором основных правил 3.1 или более ранней версии, при использовании регулярных выражений, совместимых с Perl (PCRE), при выполнении утверждений lookahead и lookbehind (отрицательных или положительных) вы можете столкнуться с проблемами.

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

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

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

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

• Для захвата заголовка запроса необходимо использовать {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}. В то время как для заголовка ответа 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-соединении.
проверка клиентского сертификата	Результат верификации сертификата клиента. В режиме passthrough для mTLS: PASSTHROUGH, когда клиент предъявляет сертификат, или NONE, когда клиент его не предъявляет. В строгом режиме mTLS: УСПЕХ , когда клиент представляет действительный сертификат. В строгом режиме Application Gateway возвращает HTTP 400 для отсутствующего или недействительного клиентского сертификата перед пересылкой запроса, поэтому бэкенд никогда не получает значения. Чтобы просмотреть эти результаты, используйте свойство sslClientVerify в журнале доступа.

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

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

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

Удалите IP-адрес встроенного прокси для использования с функцией источника X-Forwarded-For в брандмауэре серверной части

Некоторые сторонние брандмауэры, также называемые сетевыми виртуальными устройствами (NVA), определяют исходный IP-адрес с помощью входящего X-Forwarded-For заголовка вместо IP-адреса источника пакета, который в противном случае будет отражать IP-адрес шлюза приложений. Во многих случаях NVAs отображают только последний IP-адрес в заголовке.

Если запрос проходит через несколько прокси-серверов (например, клиент —> Azure Front Door —> Шлюз приложений —> NVA), последний IP-адрес в X-Forwarded-For заголовке может представлять Azure Front Door, а не исходный IP-адрес клиента. Чтобы сохранить IP-адрес клиента, можно настроить правило перезаписи шлюза приложений, чтобы задать X-Forwarded-For заголовок переменной http_req_X-Forwarded-For сервера. Эта конфигурация предотвращает добавление шлюзом приложений IP-адреса Azure Front Door или других промежуточных обратных прокси-серверов, как это показано на следующем снимке экрана.

При этом записывается входящий заголовок X-Forwarded-For, который будет исходным IP-адресом клиента, и пересылает его as-is вместо добавления IP-адреса AFD или прокси-сервера в заголовок, позволяя NVA отображать и оценивать исходный IP-адрес клиента.

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

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

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

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

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

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

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

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

1. Создайте правило перезаписи с условием, которое проверяет, содержит ли заголовок расположения в ответе azurewebsites.net. Введите шаблон "(https?)://. azurewebsites.net(.).

2. Выполните действие по перезаписи заголовка Location, чтобы в нем использовалось имя узла шлюза приложений. Введите {http_resp_Location_1}://contoso.com{http_resp_Location_2} в качестве значения заголовка. Кроме того, можно также использовать переменную сервера host, чтобы задать имя узла в соответствии с исходным запросом.

   

Реализация безопасности заголовков HTTP для предотвращения возникновения уязвимостей

Вы можете устранить ряд уязвимостей системы безопасности, реализовав необходимые заголовки в ответе приложения. Эти заголовки безопасности включают X-XSS-Protection, Strict-Transport-Security и Content-Security-Policy. Задать эти заголовки для всех ответов можно с помощью шлюза приложений.

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

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

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

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

Вы можете оценить 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-адреса или перезаписи заголовка Host с брандмауэром веб-приложений (SKU WAF_v2)

При настройке перезаписи URL или перезаписи заголовка Host проверка 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