Behoud de oorspronkelijke HTTP-hostnaam tussen een omgekeerde proxy en de bijbehorende back-endwebtoepassing

U wordt aangeraden de oorspronkelijke HTTP-hostnaam te behouden wanneer u een omgekeerde proxy voor een webtoepassing gebruikt. Het hebben van een andere hostnaam bij de omgekeerde proxy dan de hostnaam die aan de back-endtoepassingsserver wordt verstrekt, kan leiden tot cookies of omleidings-URL's die niet goed werken. De sessiestatus kan bijvoorbeeld verloren gaan, verificatie kan mislukken of back-end-URL's kunnen per ongeluk worden blootgesteld aan eindgebruikers. U kunt deze problemen voorkomen door de hostnaam van de eerste aanvraag te behouden, zodat de toepassingsserver hetzelfde domein ziet als de webbrowser.

Deze richtlijnen zijn met name van toepassing op toepassingen die worden gehost in PaaS-aanbiedingen (Platform as a Service), zoals Azure-app Service en Azure Spring Apps. Dit artikel bevat specifieke implementatierichtlijnen voor Azure-toepassing Gateway, Azure Front Door en Azure API Management, die vaak omgekeerde proxyservices worden gebruikt.

Als u end-to-end TLS/SSL nodig hebt (de verbinding tussen de omgekeerde proxy en de back-endservice gebruikt HTTPS), heeft de back-endservice ook een overeenkomend TLS-certificaat nodig voor de oorspronkelijke hostnaam. Deze vereiste voegt operationele complexiteit toe wanneer u certificaten implementeert en verlengt, maar veel PaaS-services bieden gratis TLS-certificaten die volledig worden beheerd.

Context

De host van een HTTP-aanvraag

In veel gevallen heeft de toepassingsserver of een onderdeel in de aanvraagpijplijn de internetdomeinnaam nodig die door de browser is gebruikt om er toegang toe te krijgen. Dit is de host van de aanvraag. Het kan een IP-adres zijn, maar meestal is het een naam zoals contoso.com (die vervolgens door de browser wordt omgezet in een IP-adres met behulp van DNS). De hostwaarde wordt doorgaans bepaald vanuit het hostonderdeel van de aanvraag-URI, die de browser naar de toepassing verzendt als de Host HTTP-header.

In sommige scenario's, met name wanneer er een omgekeerde HTTP-proxy in de aanvraagketen is, kan de oorspronkelijke hostheader worden gewijzigd voordat deze de toepassingsserver bereikt. Met een omgekeerde proxy wordt de clientnetwerksessie gesloten en wordt een nieuwe verbinding met de back-end ingesteld. In deze nieuwe sessie kan deze de oorspronkelijke hostnaam van de clientsessie overnemen of een nieuwe instellen. In het laatste geval verzendt de proxy vaak nog steeds de oorspronkelijke hostwaarde in andere HTTP-headers, zoals Forwarded of X-Forwarded-Host. Met deze waarde kunnen toepassingen de oorspronkelijke hostnaam bepalen, maar alleen als ze zijn gecodeerd om deze headers te lezen.

Waarom webplatformen de hostnaam gebruiken

Multitenant PaaS-services vereisen vaak een geregistreerde en gevalideerde hostnaam om een binnenkomende aanvraag te routeren naar de back-endserver van de juiste tenant. Dit komt doordat er doorgaans een gedeelde groep load balancers is die binnenkomende aanvragen voor alle tenants accepteert. De tenants gebruiken vaak de binnenkomende hostnaam om de juiste back-end voor de tenant van de klant op te zoeken.

Om eenvoudig aan de slag te gaan, bieden deze platforms doorgaans een standaarddomein dat vooraf is geconfigureerd om verkeer naar uw geïmplementeerde exemplaar te routeren. Voor App Service is azurewebsites.netdit standaarddomein. Elke web-app die u maakt, krijgt bijvoorbeeld contoso.azurewebsites.neteen eigen subdomein. Op dezelfde manier is azuremicroservices.io het standaarddomein voor Spring Apps en azure-api.net voor API Management.

Voor productie-implementaties gebruikt u deze standaarddomeinen niet. U geeft in plaats daarvan uw eigen domein op zodat deze overeenkomt met het merk van uw organisatie of toepassing. Kan bijvoorbeeld contoso.com achter de schermen worden omgezet in de contoso.azurewebsites.net web-app in App Service, maar dit domein mag niet zichtbaar zijn voor een eindgebruiker die de website bezoekt. Deze aangepaste contoso.com hostnaam moet echter worden geregistreerd bij de PaaS-service, zodat het platform de back-endserver kan identificeren die op de aanvraag moet reageren.

Waarom toepassingen de hostnaam gebruiken

Twee veelvoorkomende redenen waarom een toepassingsserver de hostnaam nodig heeft, zijn het maken van absolute URL's en het uitgeven van cookies voor een specifiek domein. Bijvoorbeeld wanneer de toepassingscode het volgende moet doen:

• Retourneer een absolute in plaats van een relatieve URL in het HTTP-antwoord (hoewel websites meestal relatieve koppelingen weergeven, indien mogelijk).
• Genereer een URL die buiten het HTTP-antwoord moet worden gebruikt, waarbij relatieve URL's niet kunnen worden gebruikt, bijvoorbeeld voor het e-mailen van een koppeling naar de website naar een gebruiker.
• Genereer een absolute omleidings-URL voor een externe service. Bijvoorbeeld voor een verificatieservice zoals Microsoft Entra ID om aan te geven waar de gebruiker moet worden geretourneerd na een geslaagde verificatie.
• Http-cookies uitgeven die zijn beperkt tot een bepaalde host, zoals gedefinieerd in het kenmerk van Domain de cookie.

U kunt aan al deze vereisten voldoen door de verwachte hostnaam toe te voegen aan de configuratie van de toepassing en die statisch gedefinieerde waarde te gebruiken in plaats van de binnenkomende hostnaam op de aanvraag. Deze aanpak maakt het ontwikkelen en implementeren van toepassingen echter ingewikkeld. Bovendien kan één installatie van de toepassing meerdere hosts bedienen. Een enkele web-app kan bijvoorbeeld worden gebruikt voor meerdere toepassingstenants die allemaal hun eigen unieke hostnamen hebben (zoals tenant1.contoso.com en tenant2.contoso.com).

En soms wordt de binnenkomende hostnaam gebruikt door onderdelen buiten de toepassingscode of in middleware op de toepassingsserver waarvoor u geen volledige controle hebt. Hieronder volgen een aantal voorbeelden:

• In App Service kunt u HTTPS afdwingen voor uw web-app. Hierdoor worden HTTP-aanvragen die niet veilig zijn om om te leiden naar HTTPS veroorzaakt. In dit geval wordt de binnenkomende hostnaam gebruikt om de absolute URL voor de header van Location de HTTP-omleiding te genereren.
• Spring Apps maakt gebruik van een vergelijkbare functie om HTTPS af te dwingen. Ook wordt de binnenkomende host gebruikt om de HTTPS-URL te genereren.
• App Service heeft een instelling voor ARR-affiniteit om plaksessies in te schakelen, zodat aanvragen van hetzelfde browserexemplaren altijd worden verwerkt door dezelfde back-endserver. Dit wordt uitgevoerd door de App Service-front-ends, die een cookie toevoegen aan het HTTP-antwoord. De cookie Domain is ingesteld op de binnenkomende host.
• App Service biedt verificatie- en autorisatiemogelijkheden waarmee gebruikers zich eenvoudig kunnen aanmelden en toegang kunnen krijgen tot gegevens in API's.
  • De binnenkomende hostnaam wordt gebruikt om de omleidings-URL te maken waarnaar de id-provider de gebruiker moet retourneren na een geslaagde verificatie.
  • Als u deze functie inschakelt, wordt ook HTTP-naar-HTTPS-omleiding ingeschakeld. Opnieuw wordt de binnenkomende hostnaam gebruikt om de omleidingslocatie te genereren.

Waarom u de hostnaam misschien wilt overschrijven

Stel dat u een webtoepassing maakt in App Service met een standaarddomein van contoso.azurewebsites.net. (Of in een andere service zoals Spring Apps.) U hebt geen aangepast domein geconfigureerd in App Service. Als u een omgekeerde proxy wilt plaatsen, zoals Application Gateway (of een vergelijkbare service) vóór deze toepassing, stelt u de DNS-record in om contoso.com te worden omgezet in het IP-adres van Application Gateway. Het ontvangt daarom de aanvraag van contoso.com de browser en is geconfigureerd om die aanvraag door te sturen naar het IP-adres dat contoso.azurewebsites.net wordt omgezet in: dit is de laatste back-endservice voor de aangevraagde host. In dit geval herkent contoso.com App Service het aangepaste domein echter niet en weigert alle binnenkomende aanvragen voor deze hostnaam. Er kan niet worden bepaald waar de aanvraag moet worden gerouteerd.

Het lijkt erop dat de eenvoudige manier om deze configuratie te laten werken, is het overschrijven of herschrijven van de Host header van de HTTP-aanvraag in Application Gateway en deze instellen op de waarde van contoso.azurewebsites.net. Als u dit doet, lijkt het alsof de oorspronkelijke aanvraag echt bedoeld was voor contoso.azurewebsites.net de uitgaande aanvraag van Application Gateway in plaats van contoso.com:

Op dit moment herkent App Service de hostnaam en accepteert deze de aanvraag zonder dat een aangepaste domeinnaam moet worden geconfigureerd. Application Gateway maakt het zelfs eenvoudig om de hostheader te overschrijven met de host van de back-endpool. Azure Front Door doet dit zelfs standaard.

Het probleem met deze oplossing is echter dat het kan leiden tot verschillende problemen wanneer de app de oorspronkelijke hostnaam niet ziet.

Mogelijke problemen

Onjuiste absolute URL's

Als de oorspronkelijke hostnaam niet behouden blijft en de toepassingsserver de binnenkomende hostnaam gebruikt om absolute URL's te genereren, wordt het back-enddomein mogelijk openbaar gemaakt aan een eindgebruiker. Deze absolute URL's kunnen worden gegenereerd door de toepassingscode of, zoals eerder vermeld, door platformfuncties zoals de ondersteuning voor HTTP-naar-HTTPS-omleiding in App Service en Spring Apps. In dit diagram ziet u het probleem:

1. De browser verzendt een aanvraag voor contoso.com de omgekeerde proxy.
2. De omgekeerde proxy herschrijft de hostnaam contoso.azurewebsites.net in de aanvraag naar de back-endwebtoepassing (of naar een vergelijkbaar standaarddomein voor een andere service).
3. De toepassing genereert bijvoorbeeld een absolute URL die is gebaseerd op de binnenkomende contoso.azurewebsites.net hostnaam https://contoso.azurewebsites.net/.
4. De browser volgt deze URL, die rechtstreeks naar de back-endservice gaat in plaats van terug naar de omgekeerde proxy op contoso.com.

Dit kan zelfs een beveiligingsrisico vormen in het algemene geval waarin de omgekeerde proxy ook fungeert als een webtoepassingsfirewall. De gebruiker ontvangt een URL die rechtstreeks naar de back-endtoepassing gaat en de omgekeerde proxy omzeilt.

Onjuiste omleidings-URL's

Een veelvoorkomend en specifieker geval van het vorige scenario treedt op wanneer absolute omleidings-URL's worden gegenereerd. Deze URL's zijn vereist voor identiteitsservices zoals Microsoft Entra ID wanneer u identiteitsprotocollen op basis van browsers gebruikt, zoals OpenID Verbinding maken, OAuth 2.0 of SAML 2.0. Deze omleidings-URL's kunnen worden gegenereerd door de toepassingsserver of middleware zelf, of, zoals eerder vermeld, door platformfuncties zoals de App Service-verificatie - en autorisatiemogelijkheden. In dit diagram ziet u het probleem:

1. De browser verzendt een aanvraag voor contoso.com de omgekeerde proxy.
2. De omgekeerde proxy herschrijft de hostnaam contoso.azurewebsites.net op de aanvraag naar de back-endwebtoepassing (of naar een vergelijkbaar standaarddomein voor een andere service).
3. De toepassing genereert een absolute omleidings-URL die is gebaseerd op de binnenkomende contoso.azurewebsites.net hostnaam, bijvoorbeeld https://contoso.azurewebsites.net/.
4. De browser gaat naar de id-provider om de gebruiker te verifiëren. De aanvraag bevat de gegenereerde omleidings-URL om aan te geven waar de gebruiker moet worden geretourneerd na een geslaagde verificatie.
5. Voor id-providers moeten doorgaans omleidings-URL's vooraf worden geregistreerd. Op dit moment moet de id-provider de aanvraag afwijzen omdat de opgegeven omleidings-URL niet is geregistreerd. (Het zou niet moeten worden gebruikt.) Als de omleidings-URL om een of andere reden is geregistreerd, stuurt de id-provider de browser om naar de omleidings-URL die is opgegeven in de verificatieaanvraag. In dit geval is https://contoso.azurewebsites.net/de URL .
6. De browser volgt deze URL, die rechtstreeks naar de back-endservice gaat in plaats van terug naar de omgekeerde proxy.

Gebroken cookies

Een hostnaam komt niet overeen met problemen wanneer de toepassingsserver cookies uitgeeft en de binnenkomende hostnaam gebruikt om het Domain kenmerk van de cookie samen te stellen. Het domeinkenmerk zorgt ervoor dat de cookie alleen voor dat specifieke domein wordt gebruikt. Deze cookies kunnen worden gegenereerd door de toepassingscode of, zoals eerder vermeld, door platformfuncties zoals de ARR-affiniteitsinstelling van App Service. In dit diagram ziet u het probleem:

1. De browser verzendt een aanvraag voor contoso.com de omgekeerde proxy.
2. De omgekeerde proxy herschrijft de hostnaam die contoso.azurewebsites.net in de aanvraag voor de back-endwebtoepassing staat (of naar een vergelijkbaar standaarddomein voor een andere service).
3. De toepassing genereert een cookie die gebruikmaakt van een domein op basis van de binnenkomende contoso.azurewebsites.net hostnaam. De browser slaat de cookie op voor dit specifieke domein in plaats van het contoso.com domein dat de gebruiker daadwerkelijk gebruikt.
4. De browser bevat de cookie niet bij een volgende aanvraag, contoso.com omdat het domein van contoso.azurewebsites.net de cookie niet overeenkomt met het domein van de aanvraag. De toepassing ontvangt de cookie die deze eerder heeft uitgegeven niet. Als gevolg hiervan kan de gebruiker mogelijk de status verliezen die in de cookie moet staan, of werken functies zoals ARR-affiniteit niet. Helaas genereert geen van deze problemen een fout of is deze direct zichtbaar voor de eindgebruiker. Dat maakt het lastig om problemen op te lossen.

Implementatierichtlijnen voor algemene Azure-services

Om mogelijke problemen te voorkomen die hier worden besproken, raden we u aan de oorspronkelijke hostnaam in de aanroep tussen de omgekeerde proxy en de back-endtoepassingsserver te behouden:

Back-endconfiguratie

Veel webhostingplatforms vereisen dat u expliciet de toegestane binnenkomende hostnamen configureert. In de volgende secties wordt beschreven hoe u deze configuratie implementeert voor de meest voorkomende Azure-services. Andere platforms bieden meestal vergelijkbare methoden voor het configureren van aangepaste domeinen.

Als u uw webtoepassing in App Service host, kunt u een aangepaste domeinnaam koppelen aan de web-app en voorkomen dat u de standaardhostnaam azurewebsites.net naar de back-end gebruikt. U hoeft uw DNS-resolutie niet te wijzigen wanneer u een aangepast domein aan de web-app koppelt: u kunt het domein verifiëren met behulp van een TXT record zonder dat dit van invloed is op uw normale CNAME records of A records. (Deze records worden nog steeds omgezet in het IP-adres van de omgekeerde proxy.) Als u end-to-end TLS/SSL nodig hebt, kunt u een bestaand certificaat importeren uit Key Vault of een App Service-certificaat gebruiken voor uw aangepaste domein. (Houd er rekening mee dat de gratis In dit geval kan het beheerde App Service-certificaat niet worden gebruikt, omdat hiervoor de DNS-record van het domein rechtstreeks naar App Service moet worden omgezet, niet naar de omgekeerde proxy.)

Als u Spring Apps gebruikt, kunt u ook een aangepast domein voor uw app gebruiken om te voorkomen dat u de azuremicroservices.io hostnaam gebruikt. U kunt een bestaand of zelfondertekend certificaat importeren als u end-to-end TLS/SSL nodig hebt.

Als u een omgekeerde proxy hebt vóór API Management (die zelf ook fungeert als een omgekeerde proxy), kunt u een aangepast domein op uw API Management-exemplaar configureren om te voorkomen dat de azure-api.net hostnaam wordt gebruikt. U kunt een bestaand of gratis beheerd certificaat importeren als u end-to-end TLS/SSL nodig hebt. Zoals eerder vermeld, zijn API's echter minder gevoelig voor de problemen die worden veroorzaakt door niet-overeenkomende hostnamen, dus deze configuratie is mogelijk niet zo belangrijk.

Als u uw toepassingen op andere platforms host, zoals op Kubernetes of rechtstreeks op virtuele machines, is er geen ingebouwde functionaliteit die afhankelijk is van de binnenkomende hostnaam. U bent verantwoordelijk voor de wijze waarop de hostnaam wordt gebruikt in de toepassingsserver zelf. De aanbeveling om de hostnaam te behouden, is doorgaans nog steeds van toepassing op onderdelen in uw toepassing die hiervan afhankelijk zijn, tenzij u uw toepassing specifiek op de hoogte stelt van omgekeerde proxy's en de forwarded of X-Forwarded-Host headers respecteert, bijvoorbeeld.

Omgekeerde proxyconfiguratie

Wanneer u de back-ends in de omgekeerde proxy definieert, kunt u nog steeds het standaarddomein van de back-endservice gebruiken, bijvoorbeeld https://contoso.azurewebsites.net/. Deze URL wordt gebruikt door de omgekeerde proxy om het juiste IP-adres voor de back-endservice op te lossen. Als u het standaarddomein van het platform gebruikt, is het IP-adres altijd gegarandeerd correct. Normaal gesproken kunt u het openbare domein niet gebruiken, bijvoorbeeld contoso.comomdat het moet worden omgezet in het IP-adres van de omgekeerde proxy zelf. (Tenzij u geavanceerdere TECHNIEKEN voor DNS-omzetting gebruikt, zoals split-horizon DNS).

Met de meeste omgekeerde proxy's kunt u configureren welke hostnaam wordt doorgegeven aan de back-endservice. In de volgende informatie wordt uitgelegd hoe u ervoor kunt zorgen dat voor de meest voorkomende Azure-services de oorspronkelijke hostnaam van de binnenkomende aanvraag wordt gebruikt.

Application Gateway

Als u Application Gateway als omgekeerde proxy gebruikt, kunt u ervoor zorgen dat de oorspronkelijke hostnaam behouden blijft door Onderdrukking met nieuwe hostnaam uit te schakelen op de back-end-HTTP-instelling. Als u dit doet, worden zowel de hostnaam kiezen van het back-endadres als overschrijven met een specifieke domeinnaam uitgeschakeld. (Beide instellingen overschrijven de hostnaam.) In de Eigenschappen van Azure Resource Manager voor Application Gateway komt deze configuratie overeen met het instellen van de hostName eigenschap op null en pickHostNameFromBackendAddress naar false.

Omdat statustests buiten de context van een binnenkomende aanvraag worden verzonden, kunnen ze niet dynamisch de juiste hostnaam bepalen. In plaats daarvan moet u een aangepaste statustest maken, hostnaam kiezen uitschakelen uit de HTTP-instellingen van de back-end en expliciet de hostnaam opgeven. Voor deze hostnaam moet u ook een geschikt aangepast domein gebruiken voor consistentie. (U kunt echter hier het standaarddomein van het hostingplatform gebruiken, omdat statustests onjuiste cookies negeren of omleidings-URL's in het antwoord.)

Azure Front Door

Als u Azure Front Door gebruikt, kunt u voorkomen dat u de hostnaam overschrijft door de back-endhostheader leeg te laten in de definitie van de back-endpool. In de Resource Manager-definitie van de back-endpool komt deze configuratie overeen met de instelling backendHostHeader .null

Als u Azure Front Door Standard of Premium gebruikt, kunt u de hostnaam behouden door de hostheader van de oorspronkelijke host leeg te laten in de oorspronkelijke definitie. In de Resource Manager-definitie van de oorsprong komt deze configuratie overeen met de instelling originHostHeader .null

API Management

Standaard overschrijft API Management de hostnaam die naar de back-end wordt verzonden met het hostonderdeel van de WEBservice-URL van de API (die overeenkomt met de waarde van de serviceUrlResource Manager-definitie van de API).

U kunt API Management dwingen om in plaats daarvan de hostnaam van de binnenkomende aanvraag te gebruiken door als volgt een inboundHTTP-headerbeleid instellen toe te voegen:

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

Zoals eerder vermeld, zijn API's echter minder gevoelig voor de problemen die worden veroorzaakt door niet-overeenkomende hostnamen, dus deze configuratie is mogelijk niet zo belangrijk.

Volgende stappen

• App Service
• Spring-apps
• Application Gateway
• Azure Front Door
• API Management

Verwante resources

• Zero-trust-netwerk voor webtoepassingen met Azure Firewall en Application Gateway
• API's beveiligen met Application Gateway en API Management
• Bedrijfsimplementatie met behulp van App Services Environment