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 jsou Azure App Service a azure Spring Apps. Tento článek obsahuje specifické pokyny k implementaci pro azure Application Gateway, azure Front Doora 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 hostitele požadavku. Může to být IP adresa, ale obvykle se jedná o název, jako je contoso.com (který prohlížeč pak přeloží na IP adresu pomocí DNS). Hodnota hostitele je obvykle určena ze hostitelské součásti identifikátoru URI požadavku, kterou prohlížeč odesílá do aplikace jako hlavičku Host HTTP.

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 do jiných hlaviček HTTP, jako je 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 App Service je tato výchozí doména azurewebsites.net. Každá webová aplikace, kterou vytvoříte, získá vlastní subdoménu, například contoso.azurewebsites.net. Podobně je výchozí doména azuremicroservices.io pro Azure Spring Apps a azure-api.net pro 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. Například contoso.com by se mohla vyřešit na pozadí webové aplikace contoso.azurewebsites.net 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í název hostitele contoso.com 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 Domain souboru 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. Tady je 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 pro hlavičku Location přesměrování HTTP.
• Azure Spring Apps používá podobnou funkci k vynuceníHTTPS. 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. Domain souboru cookie je nastavená na příchozího hostitele.
• App Service poskytuje možnosti ověřování a autorizace, aby se uživatelé mohli snadno přihlásit 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 ve službě App Service vytvoříte webovou aplikaci, 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 pro contoso.com přeložit na IP adresu služby Application Gateway. Proto obdrží požadavek na contoso.com z prohlížeče a je nakonfigurovaný tak, aby tento požadavek předával IP adrese, na kterou se contoso.azurewebsites.net překládá: jedná se o konečnou back-endovou službu požadovaného hostitele. V takovém 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 hlavičku Host 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ý pro 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. Application Gateway ve skutečnosti usnadňuje přepsání hlavičky hostitele hostitele pomocí hostitele back-endového fondu. Azure Front Door to dělá 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 žádost o contoso.com reverznímu proxy serveru.
2. Reverzní proxy přepíše název hostitele tak, aby 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 absolutní adresu URL založenou na příchozím názvu hostitele contoso.azurewebsites.net, například https://contoso.azurewebsites.net/.
4. Prohlížeč se řídí touto adresou URL, která jde přímo do back-endové služby, nikoli zpět na reverzní proxy v 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 jsou funkce služby App Service ověřování a autorizace. Tento diagram znázorňuje problém:

1. Prohlížeč odešle žádost o contoso.com reverznímu proxy serveru.
2. Reverzní proxy přepíše název hostitele tak, aby 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 absolutní adresu URL pro přesměrování založenou na příchozím názvu hostitele contoso.azurewebsites.net, například https://contoso.azurewebsites.net/.
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 adresa URL https://contoso.azurewebsites.net/.
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ává soubory cookie a používá 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 app service nastavení spřažení ARR. Tento diagram znázorňuje problém:

1. Prohlížeč odešle žádost o contoso.com reverznímu proxy serveru.
2. Reverzní proxy přepíše název hostitele, který má být contoso.azurewebsites.net v požadavku back-end webové aplikaci (nebo podobné výchozí doméně pro jinou službu).
3. Aplikace vygeneruje soubor cookie, který používá doménu na základě příchozího názvu hostitele contoso.azurewebsites.net. 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 na 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 názvu hostitele azurewebsites.net 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í TXT záznamu, aniž by to mělo vliv na běžné záznamy CNAME nebo A. (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átu služby App Service pro vaši vlastní doménu. (Všimněte si, že v tomto případě není možné použít bezplatný 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 použití názvu hostitele azuremicroservices.io. 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 api Management (který se také chová jako reverzní proxy server), můžete nakonfigurovat vlastní doménu ve vaší instanci služby API Management vyhnout se použití názvu hostitele azure-api.net. 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ě neuvědomíte reverzní proxy servery a respektujete například forwarded 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, například https://contoso.azurewebsites.net/. 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. Veřejnou doménu, jako je contoso.com, obvykle nemůžete použít, 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, jako je 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 používáte Application Gateway jako reverzní proxy server, můžete zajistit, aby původní název hostitele zůstal zachován zakázáním Přepsání novým názvem hostitele v nastavení HTTP back-endu. Tím zakážete Vybrat název hostitele z back-endové adresy i Přepsání konkrétním názvem domény. (Obě tato nastavení přepíší název hostitele.) Ve vlastnostech Azure Resource Manageru pro službu Application Gatewaytato konfigurace odpovídá nastavení vlastnosti hostName 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 Vybrat název hostitele z nastavení HTTP back-endua 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 název hostitele zachovat tak, že v definici zdroje ponecháte hlavičku původu prázdnou. V definici Resource Managerupůvodu tato konfigurace odpovídá nastavení originHostHeader na null.

API Management

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

Službu API Management můžete vynutit, aby místo toho použila název hostitele příchozího požadavku přidáním hlavičky 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
• aplikace Spring Apps
• služby Application Gateway
• azure Front Door
• API Management

Související prostředky

• síť nulové důvěryhodnosti pro webové aplikace s využitím služby Azure Firewall a služby Application Gateway
• Chránit rozhraní API pomocí služby Application Gateway a služby API Management
• podnikové nasazení pomocí služby App Services Environment