Zachování původního názvu hostitele HTTP mezi reverzním proxy serverem a back-endovou webovou aplikací

Při použití reverzního proxy serveru před webovou aplikací doporučujeme zachovat původní název hostitele HTTP. Mít jiný název hostitele na reverzním proxy serveru, než který je poskytnut back-end aplikační server, může vést k souborům cookie nebo adresám URL přesměrování, které nefungují správně. Stav relace se může například ztratit, ověřování může selhat nebo adresy URL back-endu mohou být neúmyslně vystaveny koncovým uživatelům. Těmto problémům se můžete vyhnout zachováním názvu hostitele počátečního požadavku, aby aplikační server viděl stejnou doménu jako webový prohlížeč.

Tyto pokyny platí zejména pro aplikace hostované v nabídkách paaS (platforma jako služba), jako je Aplikace Azure Service a Azure Spring Apps. Tento článek obsahuje konkrétní pokyny k implementaci pro Aplikace Azure lication Gateway, Azure Front Door a Azure API Management, které se běžně používají služby reverzního proxy serveru.

Pokud potřebujete kompletní protokol TLS/SSL (připojení mezi reverzním proxy serverem a back-endovou službou používá protokol HTTPS), back-endová služba také potřebuje odpovídající certifikát TLS pro původní název hostitele. Tento požadavek zvyšuje provozní složitost při nasazování a obnovování certifikátů, ale mnoho služeb PaaS nabízí bezplatné certifikáty TLS, které jsou plně spravované.

Kontext

Hostitel požadavku HTTP

V mnoha případech aplikační server nebo některá komponenta v kanálu požadavku potřebuje název internetové domény, který prohlížeč použil pro přístup k němu. Toto je hostitel požadavku. Může to být IP adresa, ale obvykle se jedná o název, jako contoso.com je (který se pak prohlížeč přeloží na IP adresu pomocí DNS). Hodnota hostitele je obvykle určena z hostitelské komponenty identifikátoru URI požadavku, který prohlížeč odešle do aplikace jako hlavičku HostHTTP.

V některých scénářích, zejména pokud je v řetězu požadavků reverzní proxy server HTTP, se původní hlavička hostitele může změnit předtím, než dosáhne aplikačního serveru. Reverzní proxy server zavře relaci klientské sítě a nastaví nové připojení k back-endu. V této nové relaci může buď přenést původní název hostitele relace klienta, nebo nastavit nový. V druhém případě proxy často stále odesílá původní hodnotu hostitele v jiných hlavičkách HTTP, například Forwarded nebo X-Forwarded-Host. Tato hodnota umožňuje aplikacím určit původní název hostitele, ale pouze v případě, že jsou kódované pro čtení těchto hlaviček.

Proč webové platformy používají název hostitele

Víceklientské služby PaaS často vyžadují zaregistrovaný a ověřený název hostitele, aby bylo možné směrovat příchozí požadavek na back-endový server příslušného tenanta. Důvodem je to, že existuje obvykle sdílený fond nástrojů pro vyrovnávání zatížení, které přijímají příchozí požadavky pro všechny tenanty. Tenanti často používají název příchozího hostitele k vyhledání správného back-endu pro tenanta zákazníka.

Aby bylo možné snadno začít, tyto platformy obvykle poskytují výchozí doménu, která je předem nakonfigurovaná tak, aby směrovala provoz do nasazené instance. Pro Službu App Service je tato výchozí doména azurewebsites.net. Každá webová aplikace, kterou vytvoříte, získá vlastní subdoménu, contoso.azurewebsites.netnapříklad . Podobně je azuremicroservices.io výchozí doména určená pro Azure Spring Apps a azure-api.net api Management.

V produkčních nasazeních tyto výchozí domény nepoužíváte. Místo toho zadáte vlastní doménu, která bude odpovídat značce vaší organizace nebo aplikace. Může se například contoso.com vyřešit na pozadí contoso.azurewebsites.net webové aplikace ve službě App Service, ale tato doména by neměla být viditelná pro koncového uživatele, který web navštíví. Tento vlastní contoso.com název hostitele musí být zaregistrovaný ve službě PaaS, takže platforma dokáže identifikovat back-endový server, který by měl na požadavek reagovat.

Proč aplikace používají název hostitele

Dvěma běžnými důvody, proč aplikační server potřebuje název hostitele, jsou vytvoření absolutních adres URL a vydávání souborů cookie pro konkrétní doménu. Když například kód aplikace potřebuje:

• Vrátí absolutní místo relativní adresy URL v odpovědi HTTP (ačkoli obecně weby mají tendenci vykreslovat relativní odkazy, pokud je to možné).
• Vygenerujte adresu URL, která se použije mimo odpověď HTTP, kde se relativní adresy URL nedají použít, například pro odeslání odkazu na web uživateli.
• Vygenerujte absolutní adresu URL přesměrování pro externí službu. Například ověřovací službě, jako je ID Microsoft Entra, aby bylo možné určit, kde by měl po úspěšném ověření vrátit uživatele.
• Vydávat soubory cookie HTTP, které jsou omezeny na určitého hostitele, jak je definováno v atributu Domainsouboru cookie.

Všechny tyto požadavky můžete splnit tak, že do konfigurace aplikace přidáte očekávaný název hostitele a použijete tuto staticky definovanou hodnotu místo názvu příchozího hostitele v požadavku. Tento přístup ale komplikuje vývoj a nasazení aplikací. Jedna instalace aplikace může také obsluhovat více hostitelů. Jednu webovou aplikaci je například možné použít pro více tenantů aplikací, kteří mají vlastní jedinečné názvy hostitelů (například tenant1.contoso.com a tenant2.contoso.com).

A někdy se název příchozího hostitele používá komponentami mimo kód aplikace nebo middleware na aplikačním serveru, u kterého nemáte úplnou kontrolu. Několik příkladů:

• Ve službě App Service můžete vynutit https pro webovou aplikaci. Tím dojde k tomu, že se všechny požadavky HTTP, které nejsou zabezpečené, přesměrovávají na HTTPS. V tomto případě se název příchozího hostitele používá k vygenerování absolutní adresy URL hlavičky Location přesměrování HTTP.
• Azure Spring Apps používá k vynucení HTTPS podobnou funkci. Používá také příchozího hostitele k vygenerování adresy URL HTTPS.
• Služba App Service má nastavení spřažení ARR pro povolení rychlých relací, aby žádosti ze stejné instance prohlížeče vždy obsluhoval stejný back-endový server. To provádí front-end služby App Service, který do odpovědi HTTP přidá soubor cookie. Soubor cookie Domain je nastavený na příchozího hostitele.
• App Service poskytuje možnosti ověřování a autorizace, které uživatelům umožňují snadno přihlásit se a přistupovat k datům v rozhraních API.
  • Název příchozího hostitele slouží k vytvoření adresy URL pro přesměrování, na kterou musí zprostředkovatel identity po úspěšném ověření vrátit uživatele.
  • Povolení této funkce ve výchozím nastavení zapne také přesměrování HTTP-to-HTTPS. Znovu se k vygenerování umístění pro přesměrování použije název příchozího hostitele.

Proč může být lákavé přepsat název hostitele

Řekněme, že vytvoříte webovou aplikaci ve službě App Service, která má výchozí doménu contoso.azurewebsites.net. (Nebo v jiné službě, jako je Azure Spring Apps.) Nenakonfigurovali jste vlastní doménu ve službě App Service. Pokud chcete před tuto aplikaci umístit reverzní proxy server, jako je Application Gateway (nebo jakákoli podobná služba), nastavíte záznam DNS tak contoso.com , aby se přeložil na IP adresu služby Application Gateway. Proto obdrží požadavek z contoso.com prohlížeče a je nakonfigurovaný tak, aby tento požadavek předával IP adrese, na kterou contoso.azurewebsites.net se překládá: jedná se o konečnou back-endovou službu požadovaného hostitele. V tomto případě ale App Service nerozpozná contoso.com vlastní doménu a odmítne všechny příchozí požadavky na tento název hostitele. Nemůže určit, kam se má požadavek směrovat.

Může to vypadat jako snadný způsob, jak tuto konfiguraci provést, je přepsat nebo přepsat Host hlavičku požadavku HTTP ve službě Application Gateway a nastavit ji na hodnotu contoso.azurewebsites.net. Pokud ano, odchozí požadavek ze služby Application Gateway se zdá, že původní požadavek byl opravdu určený contoso.azurewebsites.net místo contoso.com:

V tomto okamžiku služba App Service rozpozná název hostitele a přijme požadavek bez nutnosti konfigurace vlastního názvu domény. Služba Application Gateway ve skutečnosti usnadňuje přepsání hlavičky hostitele hostitelem hostitele hostitelem back-endového fondu. Azure Front Door to dělá i ve výchozím nastavení.

Problém s tímto řešením ale může vést k různým problémům, když aplikace nevidí původní název hostitele.

Potenciální problémy

Nesprávné absolutní adresy URL

Pokud se původní název hostitele nezachová a aplikační server použije k vygenerování absolutních adres URL příchozího hostitele, může být back-endová doména zpřístupněna koncovému uživateli. Tyto absolutní adresy URL mohou být generovány kódem aplikace nebo podle výše uvedených funkcí platformy, jako je podpora přesměrování HTTP-to-HTTPS ve službě App Service a Azure Spring Apps. Tento diagram znázorňuje problém:

1. Prohlížeč odešle požadavek contoso.com na reverzní proxy server.
2. Reverzní proxy přepíše název contoso.azurewebsites.net hostitele do požadavku na back-endovou webovou aplikaci (nebo podobnou výchozí doménu pro jinou službu).
3. Aplikace vygeneruje absolutní adresu URL založenou na názvu příchozího contoso.azurewebsites.net hostitele, https://contoso.azurewebsites.net/například .
4. Prohlížeč se řídí touto adresou URL, která jde přímo do back-endové služby, a ne zpět na reverzní proxy server na adrese contoso.com.

To může dokonce představovat bezpečnostní riziko v běžném případě, kdy reverzní proxy server slouží také jako firewall webových aplikací. Uživatel obdrží adresu URL, která přejde přímo do back-endové aplikace a obchází reverzní proxy server.

Nesprávné adresy URL pro přesměrování

Při generování absolutních adres URL pro přesměrování dochází k běžnému a konkrétnějšímu případu předchozího scénáře. Tyto adresy URL vyžadují služby identit, jako je Microsoft Entra ID, pokud používáte protokoly identit založené na prohlížeči, jako je OpenID Connect, Open Authorization (OAuth) 2.0 nebo SAML (Security Assertion Markup Language) 2.0. Tyto adresy URL přesměrování můžou generovat aplikační server nebo samotný middleware, nebo podle výše uvedených funkcí platformy, jako je ověřování a autorizační funkce služby App Service. Tento diagram znázorňuje problém:

1. Prohlížeč odešle požadavek contoso.com na reverzní proxy server.
2. Reverzní proxy přepíše název contoso.azurewebsites.net hostitele na požadavek na back-endovou webovou aplikaci (nebo podobnou výchozí doménu pro jinou službu).
3. Aplikace vygeneruje absolutní adresu URL pro přesměrování založenou na názvu příchozího contoso.azurewebsites.net hostitele, https://contoso.azurewebsites.net/například .
4. Prohlížeč přejde na zprostředkovatele identity a ověří uživatele. Požadavek obsahuje vygenerovanou adresu URL pro přesměrování, která označuje, kde se má uživatel po úspěšném ověření vrátit.
5. Zprostředkovatelé identity obvykle vyžadují, aby se adresy URL přesměrování zaregistrovaly předem, takže v tomto okamžiku by zprostředkovatel identity měl požadavek odmítnout, protože zadaná adresa URL přesměrování není zaregistrovaná. (Nemělo se používat.) Pokud je z nějakého důvodu adresa URL přesměrování zaregistrovaná, poskytovatel identity ale přesměruje prohlížeč na adresu URL přesměrování, která je zadaná v žádosti o ověření. V tomto případě je https://contoso.azurewebsites.net/adresa URL .
6. Prohlížeč se řídí touto adresou URL, která jde přímo do back-endové služby, nikoli zpět na reverzní proxy server.

Poškozené soubory cookie

Neshoda názvů hostitelů může také vést k problémům, když aplikační server vydá soubory cookie a použije název příchozího hostitele k vytvoření Domain atributu souboru cookie. Atribut Domain zajišťuje, že se soubor cookie použije pouze pro danou konkrétní doménu. Tyto soubory cookie mohou být generovány kódem aplikace nebo podle výše uvedených funkcí platformy, jako je nastavení spřažení ARR služby App Service. Tento diagram znázorňuje problém:

1. Prohlížeč odešle požadavek contoso.com na reverzní proxy server.
2. Reverzní proxy přepíše název hostitele tak, aby byl contoso.azurewebsites.net v požadavku na back-endovou webovou aplikaci (nebo do podobné výchozí domény pro jinou službu).
3. Aplikace vygeneruje soubor cookie, který používá doménu na základě názvu příchozího contoso.azurewebsites.net hostitele. Prohlížeč ukládá soubor cookie pro tuto konkrétní doménu, nikoli contoso.com doménu, kterou uživatel skutečně používá.
4. Prohlížeč neobsahuje soubor cookie u žádného dalšího požadavku, contoso.com protože doména contoso.azurewebsites.net souboru cookie neodpovídá doméně požadavku. Aplikace neobdrží soubor cookie, který vydala dříve. V důsledku toho může uživatel přijít o stav, který má být v souboru cookie, nebo funkce, jako je spřažení ARR, nefungují. Bohužel žádný z těchto problémů nevygeneruje chybu nebo se přímo zobrazuje koncovému uživateli. To ztěžuje řešení potíží.

Pokyny k implementaci pro běžné služby Azure

Pokud se chcete vyhnout potenciálním problémům, které jsou zde popsány, doporučujeme zachovat původní název hostitele při volání mezi reverzním proxy serverem a back-endovým aplikačním serverem:

Konfigurace back-endu

Mnoho platforem hostování webů vyžaduje, abyste explicitně nakonfigurovali povolené názvy příchozích hostitelů. Následující části popisují, jak implementovat tuto konfiguraci pro nejběžnější služby Azure. Jiné platformy obvykle poskytují podobné metody konfigurace vlastních domén.

Pokud webovou aplikaci hostujete ve službě App Service, můžete k webové aplikaci připojit vlastní název domény a vyhnout se použití výchozího azurewebsites.net názvu hostitele k back-endu. Při připojování vlastní domény k webové aplikaci nemusíte měnit překlad DNS: doménu můžete ověřit pomocí záznamuTXT, aniž by to mělo vliv na běžné CNAME záznamy nebo A záznamy. (Tyto záznamy se stále přeloží na IP adresu reverzního proxy serveru.) Pokud potřebujete kompletní protokol TLS/SSL, můžete importovat existující certifikát ze služby Key Vault nebo použít certifikát služby App Service pro vlastní doménu. (Všimněte si, že bezplatná V tomto případě nejde použít spravovaný certifikát služby App Service, protože vyžaduje, aby se záznam DNS domény přeložil přímo do služby App Service, nikoli na reverzní proxy server.)

Podobně platí, že pokud používáte Spring Apps, můžete pro aplikaci použít vlastní doménu, abyste se vyhnuli azuremicroservices.io použití názvu hostitele. Pokud potřebujete kompletní protokol TLS/SSL, můžete importovat existující certifikát podepsaný svým držitelem nebo certifikát podepsaný svým držitelem.

Pokud máte reverzní proxy server před službou API Management (který sám funguje také jako reverzní proxy server), můžete ve vaší instanci služby API Management nakonfigurovat vlastní doménu, abyste se vyhnuli použití azure-api.net názvu hostitele. Pokud potřebujete kompletní protokol TLS/SSL, můžete importovat existující nebo bezplatný spravovaný certifikát. Jak jsme si poznamenali dříve, ale rozhraní API jsou méně citlivá na problémy způsobené neshodami názvů hostitelů, takže tato konfigurace nemusí být tak důležitá.

Pokud hostujete aplikace na jiných platformách, jako je Kubernetes nebo přímo na virtuálních počítačích, neexistuje žádná integrovaná funkce, která závisí na názvu příchozího hostitele. Zodpovídáte za to, jak se název hostitele používá na samotném aplikačním serveru. Doporučení k zachování názvu hostitele se obvykle vztahuje na všechny komponenty vaší aplikace, které na něm závisejí, pokud aplikaci výslovně nezadáte vědět o reverzních proxy serverech a respektujte forwarded například hlavičky nebo X-Forwarded-Host hlavičky.

Konfigurace reverzního proxy serveru

Když definujete back-endy v rámci reverzního proxy serveru, můžete stále použít výchozí doménu back-endové služby, https://contoso.azurewebsites.net/například . Tuto adresu URL používá reverzní proxy server k překladu správné IP adresy pro back-endovou službu. Pokud používáte výchozí doménu platformy, je vždy zaručená správná IP adresa. Obvykle nemůžete použít veřejnou doménu, například contoso.com, protože by se měla přeložit na IP adresu samotného reverzního proxy serveru. (Pokud nepoužíváte pokročilejší techniky překladu DNS, například Split-horizon DNS).

Většina reverzních proxy serverů umožňuje nakonfigurovat, který název hostitele se předává back-endové službě. Následující informace vysvětlují, jak zajistit, aby se u nejběžnějších služeb Azure používal původní název hostitele příchozího požadavku.

Application Gateway

Pokud jako reverzní proxy server používáte službu Application Gateway , můžete zajistit zachování původního názvu hostitele zakázáním přepsání novým názvem hostitele v nastavení HTTP back-endu. Tím zakážete možnost Vybrat název hostitele z back-endové adresy i přepsání s konkrétním názvem domény. (Obě tato nastavení přepíší název hostitele.) Ve vlastnostech Azure Resource Manageru pro Application Gateway tato konfigurace odpovídá nastavení hostName vlastnosti na null a pickHostNameFromBackendAddress na false.

Vzhledem k tomu, že sondy stavu se odesílají mimo kontext příchozího požadavku, nemůžou dynamicky určit správný název hostitele. Místo toho musíte vytvořit vlastní sondu stavu, zakázat výběr názvu hostitele z nastavení HTTP back-endu a explicitně zadat název hostitele. Pro tento název hostitele byste také měli pro konzistenci použít odpovídající vlastní doménu. (Tady byste ale mohli použít výchozí doménu hostitelské platformy, protože sondy stavu v odpovědi ignorují nesprávné soubory cookie nebo adresy URL přesměrování.)

Azure Front Door

Pokud používáte Azure Front Door, můžete se vyhnout přepsání názvu hostitele tak, že v definici back-endového fondu ponecháte hlavičku back-endového hostitele prázdnou. V definici Resource Manageru back-endového fondu odpovídá tato konfigurace nastavení backendHostHeader null.

Pokud používáte Azure Front Door Standard nebo Premium, můžete název hostitele zachovat tak, že ponecháte v definici původu prázdné záhlaví hostitele původu. V definici Resource Manageru původu tato konfigurace odpovídá nastavení originHostHeader null.

API Management

Ve výchozím nastavení služba API Management přepíše název hostitele, který se odešle na back-end, komponentou hostitele adresy URL webové služby rozhraní API (která odpovídá serviceUrl hodnotě definice Resource Manageru rozhraní API).

Službu API Management můžete vynutit, aby místo toho používala název hostitele příchozího požadavku přidáním inbound zásady hlavičky HTTP set následujícím způsobem:

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

Jak jsme si poznamenali dříve, ale rozhraní API jsou méně citlivá na problémy způsobené neshodami názvů hostitelů, takže tato konfigurace nemusí být tak důležitá.

Další kroky

• App Service
• Spring Apps
• Application Gateway
• Azure Front Door
• API Management

Související prostředky

• Síť s nulovou důvěryhodností pro webové aplikace s využitím služby Azure Firewall a služby Application Gateway
• Ochrana rozhraní API pomocí služby Application Gateway a služby API Management
• Podnikové nasazení s využitím služby App Services Environment