Zachowaj oryginalną nazwę hosta HTTP między zwrotnym serwerem proxy i jego aplikacją internetową zaplecza

Zalecamy zachowanie oryginalnej nazwy hosta HTTP podczas używania zwrotnego serwera proxy przed aplikacją internetową. Posiadanie innej nazwy hosta na zwrotnym serwerze proxy niż ta podana na serwerze aplikacji zaplecza może prowadzić do plików cookie lub adresów URL przekierowania, które nie działają prawidłowo. Na przykład stan sesji może zostać utracony, uwierzytelnianie może zakończyć się niepowodzeniem lub przypadkowo uwidocznić adresy URL zaplecza dla użytkowników końcowych. Można uniknąć tych problemów, zachowując nazwę hosta początkowego żądania, aby serwer aplikacji widział tę samą domenę co przeglądarka internetowa.

Te wskazówki dotyczą zwłaszcza aplikacji hostowanych w ofertach paaS (platform as a service), takich jak Azure App Service i Azure Spring Apps. Ten artykuł zawiera szczegółowe wskazówki dotyczące implementacji dla usługi Azure Application Gateway, usługi Azure Front Doori azure API Management, które są często używane usługi zwrotnego serwera proxy.

Jeśli potrzebujesz kompleksowego protokołu TLS/SSL (połączenie między zwrotnym serwerem proxy i usługą zaplecza używa protokołu HTTPS), usługa zaplecza wymaga również zgodnego certyfikatu TLS dla oryginalnej nazwy hosta. To wymaganie zwiększa złożoność operacyjną podczas wdrażania i odnawiania certyfikatów, ale wiele usług PaaS oferuje bezpłatne certyfikaty TLS, które są w pełni zarządzane.

Kontekst

Host żądania HTTP

W wielu przypadkach serwer aplikacji lub jakiś składnik w potoku żądania wymaga nazwy domeny internetowej, która została użyta przez przeglądarkę w celu uzyskania do niego dostępu. Jest to host żądania. Może to być adres IP, ale zazwyczaj jest to nazwa podobna do contoso.com (którą przeglądarka następnie rozpoznaje jako adres IP przy użyciu systemu DNS). Wartość hosta jest zwykle określana na podstawie składnika hosta identyfikatora URI żądania, który przeglądarka wysyła do aplikacji jako nagłówek HTTP Host.

W niektórych scenariuszach, szczególnie w przypadku wystąpienia odwrotnego serwera proxy HTTP w łańcuchu żądań, oryginalny nagłówek hosta może ulec zmianie, zanim osiągnie serwer aplikacji. Zwrotny serwer proxy zamyka sesję sieci klienta i konfiguruje nowe połączenie z zapleczem. W tej nowej sesji może ona przenieść oryginalną nazwę hosta sesji klienta lub ustawić nową. W tym drugim przypadku serwer proxy często wysyła oryginalną wartość hosta w innych nagłówkach HTTP, takich jak Forwarded lub X-Forwarded-Host. Ta wartość umożliwia aplikacjom określenie oryginalnej nazwy hosta, ale tylko wtedy, gdy są one kodowane w celu odczytania tych nagłówków.

Dlaczego platformy internetowe używają nazwy hosta

Wielodostępne usługi PaaS często wymagają zarejestrowanej i zweryfikowanej nazwy hosta w celu kierowania żądania przychodzącego do odpowiedniego serwera zaplecza dzierżawy. Jest to spowodowane tym, że zwykle istnieje współdzielona pula modułów równoważenia obciążenia, które akceptują żądania przychodzące dla wszystkich dzierżaw. Dzierżawy często używają nazwy hosta przychodzącego, aby wyszukać prawidłowy zaplecze dla dzierżawy klienta.

Aby ułatwić rozpoczęcie pracy, te platformy zazwyczaj udostępniają domenę domyślną, która jest wstępnie skonfigurowana do kierowania ruchu do wdrożonego wystąpienia. W przypadku usługi App Service ta domena domyślna to azurewebsites.net. Każda tworzona aplikacja internetowa pobiera własną poddomenę, na przykład contoso.azurewebsites.net. Podobnie domena domyślna to azuremicroservices.io dla usługi Azure Spring Apps i azure-api.net dla usługi API Management.

W przypadku wdrożeń produkcyjnych nie używasz tych domen domyślnych. Zamiast tego należy podać własną domenę, aby dostosować się do marki organizacji lub aplikacji. Na przykład contoso.com może rozpoznać w tle aplikację internetową contoso.azurewebsites.net w usłudze App Service, ale ta domena nie powinna być widoczna dla użytkownika końcowego odwiedzającego witrynę internetową. Ta niestandardowa nazwa hosta contoso.com musi być jednak zarejestrowana w usłudze PaaS, aby platforma mogła zidentyfikować serwer zaplecza, który powinien odpowiadać na żądanie.

Dlaczego aplikacje używają nazwy hosta

Dwa typowe przyczyny, dla których serwer aplikacji potrzebuje nazwy hosta, to konstruowanie bezwzględnych adresów URL i wystawianie plików cookie dla określonej domeny. Na przykład gdy kod aplikacji musi:

• Zwróć bezwzględny, a nie względny adres URL w odpowiedzi HTTP (chociaż ogólnie witryny internetowe mają tendencję do renderowania względnych linków, gdy jest to możliwe).
• Wygeneruj adres URL, który ma być używany poza odpowiedzią HTTP, gdzie nie można używać względnych adresów URL, na przykład w przypadku wiadomości e-mail z linkiem do witryny internetowej dla użytkownika.
• Wygeneruj bezwzględny adres URL przekierowania dla usługi zewnętrznej. Na przykład do usługi uwierzytelniania, takiej jak Microsoft Entra ID, aby wskazać, gdzie powinien zwrócić użytkownika po pomyślnym uwierzytelnieniu.
• Wydaj pliki cookie HTTP, które są ograniczone do określonego hosta, zgodnie z definicją w Domain atrybutu pliku cookie.

Wszystkie te wymagania można spełnić, dodając oczekiwaną nazwę hosta do konfiguracji aplikacji i używając tej statycznie zdefiniowanej wartości zamiast nazwy przychodzącego hosta w żądaniu. Jednak takie podejście komplikuje tworzenie i wdrażanie aplikacji. Ponadto pojedyncza instalacja aplikacji może obsługiwać wiele hostów. Można na przykład użyć jednej aplikacji internetowej dla wielu dzierżaw aplikacji, które mają własne unikatowe nazwy hostów (na przykład tenant1.contoso.com i tenant2.contoso.com).

Czasami nazwa hosta przychodzącego jest używana przez składniki spoza kodu aplikacji lub oprogramowania pośredniczącego na serwerze aplikacji, nad którym nie masz pełnej kontroli. Oto kilka przykładów:

• W usłudze App Service można wymuszać HTTPS dla aplikacji internetowej. Spowoduje to, że wszystkie żądania HTTP, które nie są bezpieczne do przekierowania do protokołu HTTPS. W takim przypadku nazwa hosta przychodzącego jest używana do generowania bezwzględnego adresu URL dla nagłówka Location przekierowania HTTP.
• Usługa Azure Spring Apps używa podobnej funkcji, aby wymuszaćHTTPS. Używa on również hosta przychodzącego do generowania adresu URL HTTPS.
• Usługa App Service ma ustawienie koligacji ARR w celu włączenia sesji sticky, dzięki czemu żądania z tego samego wystąpienia przeglądarki są zawsze obsługiwane przez ten sam serwer zaplecza. Jest to wykonywane przez frontony usługi App Service, które dodają plik cookie do odpowiedzi HTTP. Domain pliku cookie jest ustawiony na hosta przychodzącego.
• Usługa App Service zapewnia możliwości uwierzytelniania i autoryzacji, aby umożliwić użytkownikom logowanie się i uzyskiwanie dostępu do danych w interfejsach API.
  • Nazwa hosta przychodzącego służy do konstruowania adresu URL przekierowania, do którego dostawca tożsamości musi zwrócić użytkownika po pomyślnym uwierzytelnieniu.
  • Włączenie tej funkcji domyślnie włącza również przekierowywanie HTTP-to-HTTPS. Ponownie nazwa hosta przychodzącego jest używana do generowania lokalizacji przekierowania.

Dlaczego warto zastąpić nazwę hosta

Załóżmy, że tworzysz aplikację internetową w usłudze App Service, która ma domyślną domenę contoso.azurewebsites.net. (Lub w innej usłudze, takiej jak Azure Spring Apps). Nie skonfigurowano domeny niestandardowej w usłudze App Service. Aby umieścić zwrotny serwer proxy, taki jak Application Gateway (lub dowolna podobna usługa) przed tą aplikacją, należy ustawić rekord DNS dla contoso.com, aby rozpoznać adres IP usługi Application Gateway. W związku z tym otrzymuje żądanie contoso.com z przeglądarki i jest skonfigurowany do przekazywania tego żądania do adresu IP, który contoso.azurewebsites.net rozpozna: jest to ostateczna usługa zaplecza dla żądanego hosta. W takim przypadku usługa App Service nie rozpoznaje jednak contoso.com domeny niestandardowej i odrzuca wszystkie żądania przychodzące dla tej nazwy hosta. Nie może określić, gdzie należy kierować żądanie.

Może się wydawać, że łatwym sposobem wykonania tej konfiguracji jest zastąpienie lub ponowne zapisywanie nagłówka Host żądania HTTP w usłudze Application Gateway i ustawienie go na wartość contoso.azurewebsites.net. Jeśli tak, wychodzące żądanie z usługi Application Gateway sprawia, że wygląda na to, że oryginalne żądanie było naprawdę przeznaczone do contoso.azurewebsites.net zamiast contoso.com:

W tym momencie usługa App Service rozpoznaje nazwę hosta i akceptuje żądanie bez konieczności konfigurowania niestandardowej nazwy domeny. W rzeczywistości usługa Application Gateway ułatwia zastąpienie nagłówka hosta hostem puli zaplecza. usługa Azure Front Door nawet domyślnie.

Problem z tym rozwiązaniem polega jednak na tym, że może to spowodować różne problemy, gdy aplikacja nie widzi oryginalnej nazwy hosta.

Potencjalne problemy

Nieprawidłowe bezwzględne adresy URL

Jeśli oryginalna nazwa hosta nie jest zachowana, a serwer aplikacji używa nazwy hosta przychodzącego do generowania bezwzględnych adresów URL, domena zaplecza może zostać ujawniona użytkownikowi końcowemu. Te bezwzględne adresy URL mogą być generowane przez kod aplikacji lub, jak wspomniano wcześniej, przez funkcje platformy, takie jak obsługa przekierowania HTTP-to-HTTPS w usługach App Service i Azure Spring Apps. Ten diagram ilustruje problem:

1. Przeglądarka wysyła żądanie contoso.com do zwrotnego serwera proxy.
2. Zwrotny serwer proxy ponownie zapisuje nazwę hosta, aby contoso.azurewebsites.net w żądaniu do aplikacji internetowej zaplecza (lub podobnej domeny domyślnej dla innej usługi).
3. Aplikacja generuje bezwzględny adres URL oparty na nazwie hosta przychodzącego contoso.azurewebsites.net, na przykład https://contoso.azurewebsites.net/.
4. Przeglądarka jest zgodna z tym adresem URL, który przechodzi bezpośrednio do usługi zaplecza, a nie z powrotem do zwrotnego serwera proxy w contoso.com.

Może to nawet stanowić zagrożenie bezpieczeństwa w typowym przypadku, w którym zwrotny serwer proxy służy również jako zapora aplikacji internetowej. Użytkownik otrzymuje adres URL, który przechodzi bezpośrednio do aplikacji zaplecza i pomija zwrotny serwer proxy.

Nieprawidłowe adresy URL przekierowania

Typowy i bardziej szczegółowy przypadek poprzedniego scenariusza występuje, gdy są generowane bezwzględne adresy URL przekierowania. Te adresy URL są wymagane przez usługi tożsamości, takie jak Microsoft Entra ID, gdy używasz protokołów tożsamości opartych na przeglądarce, takich jak OpenID Connect, Open Authorization (OAuth) 2.0 lub Security Assertion Markup Language (SAML) 2.0. Te adresy URL przekierowania mogą być generowane przez serwer aplikacji lub oprogramowanie pośredniczące lub, jak wspomniano wcześniej, przez funkcje platformy, takie jak usługa App Service możliwości uwierzytelniania i autoryzacji. Ten diagram ilustruje problem:

1. Przeglądarka wysyła żądanie contoso.com do zwrotnego serwera proxy.
2. Zwrotny serwer proxy ponownie zapisuje nazwę hosta, aby contoso.azurewebsites.net żądania do aplikacji internetowej zaplecza (lub podobnej domeny domyślnej dla innej usługi).
3. Aplikacja generuje bezwzględny adres URL przekierowania oparty na nazwie hosta przychodzącego contoso.azurewebsites.net, na przykład https://contoso.azurewebsites.net/.
4. Przeglądarka przechodzi do dostawcy tożsamości w celu uwierzytelnienia użytkownika. Żądanie zawiera wygenerowany adres URL przekierowania, aby wskazać, gdzie należy zwrócić użytkownika po pomyślnym uwierzytelnieniu.
5. Dostawcy tożsamości zazwyczaj wymagają zarejestrowania adresów URL przekierowania z góry, dlatego w tym momencie dostawca tożsamości powinien odrzucić żądanie, ponieważ podany adres URL przekierowania nie jest zarejestrowany. (Nie miało być używane). Jeśli z jakiegoś powodu adres URL przekierowania jest zarejestrowany, dostawca tożsamości przekierowuje przeglądarkę do adresu URL przekierowania określonego w żądaniu uwierzytelniania. W tym przypadku adres URL to https://contoso.azurewebsites.net/.
6. Przeglądarka jest zgodna z tym adresem URL, który przechodzi bezpośrednio do usługi zaplecza, a nie z powrotem do zwrotnego serwera proxy.

Uszkodzone pliki cookie

Niezgodność nazwy hosta może również prowadzić do problemów, gdy serwer aplikacji wystawia pliki cookie i używa przychodzącej nazwy hosta do konstruowania atrybutu Domain pliku cookie. Atrybut Domena zapewnia, że plik cookie będzie używany tylko dla tej konkretnej domeny. Te pliki cookie mogą być generowane przez kod aplikacji lub, jak wspomniano wcześniej, przez funkcje platformy, takie jak usługa App Service ustawienie koligacji ARR. Ten diagram ilustruje problem:

1. Przeglądarka wysyła żądanie contoso.com do zwrotnego serwera proxy.
2. Zwrotny serwer proxy ponownie zapisuje nazwę hosta, która ma być contoso.azurewebsites.net w żądaniu do aplikacji internetowej zaplecza (lub podobnej domeny domyślnej dla innej usługi).
3. Aplikacja generuje plik cookie, który używa domeny na podstawie nazwy hosta przychodzącego contoso.azurewebsites.net. Przeglądarka przechowuje plik cookie dla tej konkretnej domeny, a nie domenę contoso.com, której użytkownik rzeczywiście używa.
4. Przeglądarka nie dołącza pliku cookie do żadnego kolejnego żądania contoso.com, ponieważ domena contoso.azurewebsites.net pliku cookie nie jest zgodna z domeną żądania. Aplikacja nie otrzymuje wcześniej wystawionego pliku cookie. W związku z tym użytkownik może utracić stan, który ma znajdować się w pliku cookie, lub funkcje takie jak koligacja ARR nie działają. Niestety żaden z tych problemów nie generuje błędu lub jest widoczny bezpośrednio dla użytkownika końcowego. To utrudnia rozwiązywanie problemów.

Wskazówki dotyczące implementacji typowych usług platformy Azure

Aby uniknąć potencjalnych problemów omówionych tutaj, zalecamy zachowanie oryginalnej nazwy hosta w wywołaniu między zwrotnym serwerem proxy a serwerem aplikacji zaplecza:

Konfiguracja zaplecza

Wiele platform hostingu sieci Web wymaga jawnego skonfigurowania dozwolonych nazw hostów przychodzących. W poniższych sekcjach opisano sposób implementowania tej konfiguracji dla najbardziej typowych usług platformy Azure. Inne platformy zwykle udostępniają podobne metody konfigurowania domen niestandardowych.

Jeśli hostujesz aplikację internetową w usłudze App Service, możesz dołączyć niestandardową nazwę domeny do aplikacji internetowej i uniknąć używania domyślnej nazwy hosta azurewebsites.net w kierunku zaplecza. Nie musisz zmieniać rozpoznawania nazw DNS podczas dołączania domeny niestandardowej do aplikacji internetowej: możesz zweryfikować domenę przy użyciu rekordu TXT bez wpływu na zwykłe rekordy CNAME lub A. (Te rekordy nadal będą rozpoznawane jako adres IP zwrotnego serwera proxy). Jeśli potrzebujesz kompleksowego protokołu TLS/SSL, możesz zaimportować istniejący certyfikat z usługi Key Vault lub użyć certyfikatu usługi App Service dla domeny niestandardowej. (Należy pamiętać, że w tym przypadku nie można używać bezpłatnego certyfikatu zarządzanego usługi App Service, ponieważ wymaga on rozpoznawania rekordu DNS domeny bezpośrednio do usługi App Service, a nie zwrotnego serwera proxy).

Podobnie, jeśli używasz Spring Apps, możesz użyć domeny niestandardowej dla aplikacji, aby uniknąć używania nazwy hosta azuremicroservices.io. Jeśli potrzebujesz kompleksowego protokołu TLS/SSL, możesz zaimportować istniejący lub certyfikat z podpisem własnym.

Jeśli masz zwrotny serwer proxy przed api Management (który działa również jako zwrotny serwer proxy), możesz skonfigurować domenę niestandardową w wystąpieniu usługi API Management, aby uniknąć używania nazwy hosta azure-api.net. Jeśli potrzebujesz kompleksowego protokołu TLS/SSL, możesz zaimportować istniejący lub bezpłatny zarządzany certyfikat. Jak wspomniano wcześniej, interfejsy API są jednak mniej wrażliwe na problemy spowodowane niezgodnościami nazw hostów, więc ta konfiguracja może nie być tak ważna.

Jeśli hostujesz aplikacje na innych platformach, na przykład na platformie Kubernetes lub bezpośrednio na maszynach wirtualnych, nie ma wbudowanych funkcji, które zależą od nazwy przychodzącego hosta. Odpowiadasz za sposób używania nazwy hosta na samym serwerze aplikacji. Zalecenie dotyczące zachowania nazwy hosta zwykle dotyczy wszystkich składników w aplikacji, które są od niej zależne, chyba że aplikacja będzie wiedziała o odwrotnych serwerach proxy i przestrzegała na przykład nagłówków forwarded lub X-Forwarded-Host.

Konfiguracja zwrotnego serwera proxy

Po zdefiniowaniu zaplecza w odwrotnym serwerze proxy nadal można użyć domeny domyślnej usługi zaplecza, na przykład https://contoso.azurewebsites.net/. Ten adres URL jest używany przez zwrotny serwer proxy do rozpoznawania poprawnego adresu IP dla usługi zaplecza. Jeśli używasz domyślnej domeny platformy, adres IP jest zawsze gwarantowany jako poprawny. Zazwyczaj nie można używać domeny publicznej, takiej jak contoso.com, ponieważ powinna zostać rozpoznana jako adres IP samego zwrotnego serwera proxy. (Jeśli nie używasz bardziej zaawansowanych technik rozpoznawania nazw DNS, takich jak split-horizon DNS).

Większość zwrotnych serwerów proxy umożliwia skonfigurowanie, która nazwa hosta jest przekazywana do usługi zaplecza. Poniższe informacje wyjaśniają, jak upewnić się, że w przypadku najbardziej typowych usług platformy Azure jest używana oryginalna nazwa hosta żądania przychodzącego.

Application Gateway

Jeśli używasz Application Gateway jako zwrotnego serwera proxy, możesz upewnić się, że oryginalna nazwa hosta jest zachowywana, wyłączając przesłonięcia przy użyciu nowej nazwy hosta w ustawieniu HTTP zaplecza. Spowoduje to wyłączenie zarówno pick host name from back-end address and Override with specific domain name. (Oba te ustawienia zastępują nazwę hosta). W właściwości usługi Azure Resource Manager dla usługi Application Gatewayta konfiguracja odpowiada ustawieniu właściwości hostNamenull i pickHostNameFromBackendAddressfalse.

Ponieważ sondy kondycji są wysyłane poza kontekstem żądania przychodzącego, nie mogą dynamicznie określać poprawnej nazwy hosta. Zamiast tego należy utworzyć niestandardową sondę kondycji, wyłączyć Wybierz nazwę hosta z ustawień HTTP zapleczai jawnie określić nazwę hosta. Dla tej nazwy hosta należy również użyć odpowiedniej domeny niestandardowej w celu zapewnienia spójności. (Można jednak użyć w tym miejscu domyślnej domeny platformy hostingu, ponieważ sondy kondycji ignorują nieprawidłowe pliki cookie lub adresy URL przekierowania w odpowiedzi).

Azure Front Door

Jeśli używasz usługi Azure Front Door, możesz zachować nazwę hosta, pozostawiając nagłówek hosta pochodzenia pusty w definicji źródła. W definicji usługi Resource Manager źródłata konfiguracja odpowiada ustawieniu originHostHeadernull.

API Management

Domyślnie usługa API Management zastępuje nazwę hosta, która jest wysyłana do zaplecza przy użyciu składnika hosta adresu URL usługi internetowej interfejsu API (który odpowiada wartości serviceUrl definicji usługi Resource Manager interfejsu API).

Usługę API Management można wymusić, aby zamiast tego użyć nazwy hosta żądania przychodzącego, dodając zasady nagłówka zestawu w następujący sposób:

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

Jak wspomniano wcześniej, interfejsy API są jednak mniej wrażliwe na problemy spowodowane niezgodnościami nazw hostów, więc ta konfiguracja może nie być tak ważna.

Następne kroki

• app service
• Spring Apps
• Application Gateway
• usługi Azure Front Door
• API Management

Powiązane zasoby

• sieci zerowej zaufania dla aplikacji internetowych za pomocą usługi Azure Firewall i usługi Application Gateway
• Ochrona interfejsów API za pomocą usługi Application Gateway i usługi API Management
• wdrażanie Enterprise przy użyciu środowiska App Services Environment