Сохранение исходного имени узла HTTP между обратным прокси-сервером и серверным веб-приложением

Рекомендуется сохранить исходное имя узла HTTP при использовании обратного прокси-сервера перед веб-приложением. Если вы используете другое имя хоста в обратном прокси-сервере, чем то, что предоставлено серверу серверного приложения, это может привести к неправильной работе файлов cookie или URL-адресов перенаправления. Например, состояние сеанса может быть потеряно, проверка подлинности может не сработать, или внутренние URL могут непреднамеренно стать доступными пользователям. Чтобы избежать этих проблем, сохраните имя узла начального запроса, поэтому сервер приложений видит тот же домен, что и веб-браузер.

Это руководство особенно относится к приложениям, размещенным на платформе как услуга (PaaS), таким как Azure App Service и Azure Container Apps. В этой статье приведены конкретные рекомендации по implementation для часто используемых обратных прокси-служб, включая Azure Application Gateway, Azure Front Door и Azure API Management.

Если требуется сквозное обеспечение безопасности уровня транспортного слоя (TLS/SSL), или подключение между обратным прокси-сервером и службой back-end использует HTTPS, то служба back-end также должна иметь соответствующий сертификат TLS для исходного имени хоста. Это требование повышает операционную сложность при развертывании и продлении сертификатов, но многие службы PaaS предоставляют бесплатные сертификаты TLS, которые полностью управляются.

Хост HTTP-запроса

Во многих случаях серверу приложений или компоненту в конвейере запросов требуется доменное имя Интернета, используемое браузером для доступа к нему. Это доменное имя является узлом запроса. Хост может быть IP-адресом, но обычно это имя, например contoso.com, которое браузер затем преобразует в IP-адрес с помощью Domain Name System (DNS). Значение узла обычно определяется из компонента узла URI запроса, который браузер отправляет приложению в качестве Host заголовка HTTP.

В некоторых сценариях, особенно если в цепочке запросов есть обратный прокси-сервер HTTP, исходный заголовок узла может измениться, прежде чем он достигнет сервера приложений. Обратный прокси-сервер закрывает сеанс клиентской сети и настраивает новое подключение к серверной части. В этом новом сеансе обратный прокси-сервер может переносить исходное имя узла сеанса клиента или задать новый. Если обратный прокси-сервер задает новое имя узла, прокси-сервер часто отправляет исходное значение узла в других заголовках HTTP, например Forwarded или X-Forwarded-Host. Включение этого значения позволяет приложениям определять исходное имя узла, но только если они запрограммированы на чтение этих заголовков.

Почему веб-платформы используют имя узла

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

Чтобы упростить начало работы, эти платформы обычно предоставляют домен по умолчанию, который уже настроен для маршрутизации трафика в вашу развернутую инстанцию. Для службы приложений этот домен по умолчанию azurewebsites.net. Каждое создаваемое веб-приложение получает собственный поддомен, например contoso.azurewebsites.net. Аналогичным образом домен по умолчанию предназначен azurecontainerapps.io для приложений контейнеров и azure-api.net для управления API.

Промышленные развертывания не используют эти домены по умолчанию. Вместо этого укажите собственный домен для согласования с вашей организацией или фирменной символикой вашего приложения. Например, contoso.com может разрешить веб-приложение contoso.azurewebsites.net в службе приложений, но этот домен не должен отображаться пользователю, посещающим веб-сайт. Однако это пользовательское contoso.com имя узла должно быть зарегистрировано в службе PaaS, чтобы платформа может определить серверный сервер, который должен отвечать на запрос.

Почему приложения используют имя узла

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

• Возвращает абсолютный URL-адрес, а не относительный URL-адрес в ответе HTTP (хотя веб-сайты обычно отображают относительные ссылки).

• Создайте URL-адрес, используемый вне ответа HTTP, где относительные URL-адреса нельзя использовать, например при отправке электронной почты ссылке веб-сайта пользователю.

• Создайте абсолютный URL-адрес перенаправления для внешней службы. Например, абсолютный URL-адрес перенаправления для службы проверки подлинности, например Microsoft Entra ID, может указывать, где он возвращает пользователя после успешной проверки подлинности.

• Ограничьте HTTP cookie для определенного хоста, как указано в атрибуте файла cookieDomain.

Вы можете выполнить все эти требования, добавив ожидаемое имя узла в конфигурацию приложения и используя это статичное значение вместо входящего имени узла в запросе. Но этот подход усложняет разработку и развертывание приложений. Кроме того, одна установка приложения может обслуживать несколько узлов. Например, одно веб-приложение можно использовать для нескольких клиентов приложений, имеющих собственные уникальные имена узлов, например tenant1.contoso.com и tenant2.contoso.com.

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

• В службе приложений можно применить HTTPS для веб-приложения. Этот подход перенаправляет незащищенные HTTP-запросы на HTTPS. В этом случае имя входящего узла используется для создания абсолютного URL-адреса заголовка Location перенаправления HTTP.

• Приложения-контейнеры также могут перенаправлять HTTP-запросы на HTTPS, и они также используют входящий узел для создания URL-адреса HTTPS.

• Служба приложений имеет настройку привязки ARR, которая предоставляет сеансы с привязкой, что гарантирует, что запросы из одной сессии браузера направляются на один и тот же сервер. Интерфейс службы приложений добавляет файл cookie в ответ HTTP. Значение Domain файла cookie устанавливается для входящего хоста.

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

  • Имя входящего узла используется для создания URL-адреса перенаправления, указывающего место, куда поставщик удостоверений возвращает пользователя после аутентификации.
  • Если включить эту функцию, она также включает перенаправление с HTTP на HTTPS. Имя входящего узла используется для создания адреса перенаправления.

Переопределение имени узла не является решением

Предположим, что вы создаете веб-приложение в службе приложений или аналогичную службу, например контейнерные приложения. Узел поставляется с доменом по умолчанию contoso.azurewebsites.net.. Однако вы еще не настроили пользовательский домен в App Service. Чтобы разместить обратный прокси-сервер, например, Шлюз приложений, перед этим приложением, необходимо задать DNS-запись для contoso.com, чтобы она разрешалась в IP-адрес Шлюза приложений. Обратный прокси-сервер получает запрос contoso.com из браузера и перенаправит его в конечную точку службы приложений по адресу contoso.azurewebsites.net. Служба приложений — это окончательная серверная служба для запрошенного узла. Служба приложений не распознает личный contoso.com домен, поэтому отклоняет все входящие запросы на это имя узла. Он не может определить, куда маршрутизировать запрос.

Чтобы заставить эту конфигурацию работать, можно переопределить или перезаписать Host заголовок HTTP-запроса в Шлюзе приложений и задать его значение contoso.azurewebsites.net. Но если использовать этот подход, то исходящий запрос из Шлюза приложений будет казаться таким, будто исходный запрос предназначался для contoso.azurewebsites.net, а не для contoso.com.

Теперь служба приложений распознает имя узла и принимает запрос, не требуя настройки личного доменного имени. Шлюз приложений позволяет легко переопределить заголовок узла с узлом бекенд пула. Azure Front Door выполняет этот процесс по умолчанию. Но это решение может вызвать проблемы, если приложение не видит исходное имя узла.

Потенциальные проблемы

В следующих разделах описываются распространенные проблемы, которые могут возникнуть, когда исходное имя узла HTTP не сохраняется между обратным прокси-сервером и серверным приложением.

Неправильные абсолютные URL-адреса

Если исходное имя узла не сохраняется, а сервер приложений использует входящее имя узла для создания абсолютных URL-адресов, серверный домен может быть раскрыт пользователю. Эти абсолютные URL-адреса создаются кодом приложения или функциями платформы, такими как поддержка перенаправления HTTP-to-HTTPS в службе приложений и контейнерных приложениях. На следующей схеме показана проблема.

Диаграмма, иллюстрирующая проблему неправильных абсолютных URL-адресов.

1. Браузер отправляет запрос на contoso.com обратному прокси-серверу.

2. Обратный прокси перезаписывает имя contoso.azurewebsites.net узла в запросе на серверное веб-приложение или на аналогичный домен по умолчанию для другой службы.

3. Приложение создает абсолютный URL-адрес, основанный на имени узла входящего contoso.azurewebsites.net, например https://contoso.azurewebsites.net/.

4. Браузер следует этому URL-адресу, который переходит непосредственно в серверную службу, а не обратно на обратный прокси-сервер в contoso.com.

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

Неправильные URL-адреса перенаправления

Более конкретный случай предыдущего сценария возникает при создании абсолютных URL-адресов перенаправления. Такие службы удостоверений, как Microsoft Entra ID, требуют эти URL-адреса при использовании протоколов идентификации на основе браузера, таких как OpenID Connect (OIDC), Open Authorization (OAuth) 2.0 или SAML 2.0. Эти URL-адреса перенаправления могут создаваться сервером приложений или ПО промежуточного слоя или возможностями платформы, такими как проверка подлинности и авторизация службы приложений. На следующей схеме показана проблема.

Диаграмма, иллюстрирующая проблему неправильных URL-адресов перенаправления.

1. Браузер отправляет запрос на contoso.com обратному прокси-серверу.

2. Обратный прокси переписывает имя узла на contoso.azurewebsites.net при запросе к серверному веб-приложению или изменяет его на аналогичный домен по умолчанию для другой службы.

3. Приложение создает абсолютный URL-адрес перенаправления, основанный на имени узла входящего contoso.azurewebsites.net, например, https://contoso.azurewebsites.net/.

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

5. Провайдеры идентификации обычно требуют, чтобы URL-адреса перенаправления были зарегистрированы заранее. Поставщик удостоверений должен отклонить запрос, так как указанный URL-адрес перенаправления не зарегистрирован. Если URL-адрес перенаправления был ошибочно зарегистрирован, поставщик удостоверений перенаправляет браузер на URL-адрес перенаправления, указанный в запросе проверки подлинности. В этом случае URL-адрес https://contoso.azurewebsites.net/.

6. Браузер следует этому URL-адресу, который переходит непосредственно в серверную службу, а не обратно на обратный прокси-сервер.

Сломанные файлы cookie

Несоответствие имени узла также может вызвать проблемы, когда сервер приложений выдает файлы cookie и использует входящее имя узла для создания Domain атрибута файла cookie. Атрибут Domain гарантирует, что файл cookie используется только для этого конкретного домена. Эти файлы cookie создаются кодом приложения или функциями платформы, такими как параметр сопоставления службы приложений ARR. На следующей схеме показана проблема.

1. Браузер отправляет запрос на contoso.com обратному прокси-серверу.

2. Обратный прокси изменяет имя хоста на contoso.azurewebsites.net в запросе к серверному веб-приложению или на аналогичный домен по умолчанию для другой службы.

3. Приложение создает файл cookie, использующий домен на основе входящего имени узла contoso.azurewebsites.net. Браузер сохраняет cookie для этого конкретного домена, а не для contoso.com домена, который использует пользователь.

4. Браузер не включает файл cookie при последующем запросе contoso.com, так как домен файла cookie contoso.azurewebsites.net не соответствует домену запроса. Приложение не получает файл cookie, выданный ранее. Пользователь может потерять состояние, которое должно находиться в файле cookie, и такие функции, как привязка ARR, могут не работать. Эти проблемы не создают ошибку и не отображаются напрямую для конечного пользователя, что затрудняет устранение неполадок.

Руководство по реализации общих служб Azure

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

Диаграмма, показывающая конфигурацию, в которой сохраняется имя узла.

Конфигурация серверной части

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

Если вы размещаете веб-приложение в Службе приложений, подключите имя личного домена к веб-приложению и избегайте использования имени узла по умолчанию azurewebsites.net в серверной части. При присоединении личного домена к веб-приложению не нужно изменять разрешение DNS. Вместо этого, проверьте домен с помощью записи TXT, не влияя на ваши обычные CNAME или A записи. Эти записи по-прежнему сопоставляются с IP-адресом обратного прокси-сервера. Если вам требуется сквозной TLS/SSL, импортируйте существующий сертификат из Key Vault или используйте сертификат службы приложений для вашего пользовательского домена. В этом случае нельзя использовать бесплатный управляемый сертификат службы приложений , так как он требует записи DNS домена, а не обратного прокси-сервера, для разрешения непосредственно в службу приложений.

Если вы используете контейнерные приложения, используйте личный домен для приложения, чтобы избежать использования azurecontainerapps.io имени узла. Используйте управляемый сертификат или импортируйте существующий сертификат.

Если у вас есть обратный прокси-сервер перед управлением API, который также выступает в качестве обратного прокси-сервера, настройте личный домен в экземпляре управления API. Этот подход позволяет избежать использования azure-api.net имени узла. Если требуется сквозной протокол TLS/SSL, импортируйте существующий или бесплатный управляемый сертификат. Но API-интерфейсы менее чувствительны к проблемам, вызванным несоответствием имени узла, поэтому эта конфигурация может быть не столь важна.

Если приложения размещаются на других платформах, например в Kubernetes или непосредственно на виртуальных машинах, встроенные функции не зависят от имени входящего узла. Вы отвечаете за использование имени узла на сервере приложений. Рекомендация по сохранению имени узла по-прежнему применяется для всех компонентов в вашем приложении, которые зависят от него, если вы не сделаете свое приложение осведомленным о обратных прокси-серверах и не учитываете, например, заголовков forwarded или X-Forwarded-Host.

Обратная конфигурация прокси-сервера

При определении бекендов в обратном прокси-сервере можно по-прежнему использовать домен по умолчанию службы бекенда, например https://contoso.azurewebsites.net/. Этот URL-адрес используется обратным прокси-сервером для разрешения правильного IP-адреса серверной службы. Если вы используете домен платформы по умолчанию, IP-адрес гарантированно будет правильным. Обычно вы не можете использовать общедоступный домен, например contoso.com, так как он должен разрешаться в IP-адрес обратного прокси-сервера. Исключением из этого правила является использование более сложных методов разрешения DNS, таких как DNS с разделением горизонта.

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

Когда вы сохраняете или переопределяете имя хоста в обратном прокси-сервере, убедитесь, что сервер бэкэнда настроен на прием запроса в вашем формате.

Шлюз приложений

Если в качестве обратного прокси-сервера используется шлюз приложений, убедитесь, что исходное имя узла сохраняется, отключив переопределение с новым именем узла в параметре HTTP серверной части. Этот параметр отключает Выбор имени узла из внутреннего адреса и Переопределение с использованием конкретного доменного имени, которые оба переопределяют имя узла. В свойствах Azure Resource Manager для шлюза приложений эта конфигурация соответствует установке свойства hostName в null и pickHostNameFromBackendAddress в false.

Так как пробы работоспособности отправляются вне контекста входящего запроса, они не могут динамически определять правильное имя узла. Вместо этого создайте пользовательскую проверку работоспособности, отключите выбор имени узла из настроек HTTP серверной части и явно укажите имя узла. Для этого имени узла используйте соответствующий личный домен для согласованности. Кроме того, используйте домен по умолчанию для платформы размещения, так как пробы работоспособности игнорируют неправильные файлы cookie или url-адреса перенаправления в ответе.

Если имя хоста не сохраняется и вам нужно диагностировать полученные проблемы, см. Устранение неполадок при перенаправлении на URL-адрес App Service. Если вы не можете полностью сохранить имя узла, рекомендуется использовать перезаписи заголовков HTTP и URL-адресов в качестве частичного обходного решения.

Azure Front Door – сервис Microsoft

Если вы используете Azure Front Door, сохраните имя узла, оставив заголовок узла origin host пустым в определении источника. В определении источника Resource Manager эта конфигурация соответствует установке параметра originHostHeader на null.

API Management

По умолчанию API Management заменяет имя узла, которое отправляется на сервер, на компонент узла URL веб-службы API, который соответствует значению serviceUrl в определении Resource Manager API. Вместо этого, заставьте службу управления API использовать имя узла входящего запроса, добавив политику установки заголовка.

<inbound>
  <base />
  <set-header name="Host" exists-action="override">
    <value>@(context.Request.OriginalUrl.Host)</value>
  </set-header>
</inbound>

API менее чувствительны к проблемам, вызванным несоответствием имени узла, поэтому эта конфигурация может быть не столь важна.

Конфигурация приложений

Даже при сохранении исходного имени узла на обратном уровне прокси-сервера обратный прокси-сервер по-прежнему завершает подключение TLS клиента. Новое подключение, устанавливаемое прокси-сервером, теряет исходный IP-адрес клиента и схему HTTPS. Обычно эти значения пересылаются через часто используемые заголовки HTTP. Примеры включают X-Forwarded-For IP-адрес клиента, X-Forwarded-Proto исходную схему и X-Forwarded-Host имя исходного узла. Приложение должно быть настроено для чтения этих заголовков, чтобы правильно определить схему запроса, адрес клиента и исходную информацию узла.

Если платформа приложений не обрабатывает X-Forwarded-Proto, приложение рассматривает серверное соединение как обычный протокол HTTP, даже если пользователь подключается через HTTPS. Это неправильное представление является наиболее распространенным причиной бесконечных циклов перенаправления HTTP-to-HTTPS. Это также может привести к небезопасным флагам файлов cookie или ошибкам смешанного содержимого.

Большинство веб-платформ имеют механизм обработки перенаправленных заголовков. Просмотрите документацию платформы и настройте ее соответствующим образом. В следующих примерах рассматриваются общие платформы:

• ASP.NET Core: Используйте средство промежуточного программного обеспечения для пересылаемых заголовков.
• Java Spring Boot: Задайте server.forward-headers-strategy значение FRAMEWORK в свойствах приложения.
• Node.js Express: Задать app.set('trust proxy', <value>).

Дальнейшие действия

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

• Служба приложений
• Контейнерные приложения
• Шлюз приложений
• Azure Front Door
• Управление API

Связанные ресурсы

• Реализовать сеть Zero Trust для веб-приложений с помощью Azure Firewall и шлюза приложений Azure
• Защита API с помощью шлюза приложений и управления API
• Enterprise-развертывание, использующее App Service Environment