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ą szczególnie aplikacji hostowanych w ofertach paaS (platform as a service), takich jak aplikacja systemu Azure Service i Azure Spring Apps. Ten artykuł zawiera szczegółowe wskazówki dotyczące implementacji usług aplikacja systemu Azure Gateway, Azure Front Door i Azure API Management, które są powszechnie używanymi usługami 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 contoso.com do (którą przeglądarka następnie rozpoznaje jako adres IP przy użyciu systemu DNS). Wartość hosta jest zwykle określana ze składnika hosta identyfikatora URI żądania, który przeglądarka wysyła do aplikacji jako Host nagłówek HTTP.

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 dotyczy azuremicroservices.io usługi Azure Spring Apps i azure-api.net 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 rozwiązać problemy w tle contoso.azurewebsites.net z aplikacją internetową w usłudze App Service, ale ta domena nie powinna być widoczna dla użytkownika końcowego odwiedzającego witrynę internetową. Ta niestandardowa contoso.com nazwa hosta 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.
• Wystawiaj pliki cookie HTTP, które są ograniczone do określonego hosta zgodnie z definicją w atrybucie pliku cookie.Domain

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żesz wymusić protokół 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 nagłówka Location przekierowania HTTP.
• Usługa Azure Spring Apps używa podobnej funkcji do wymuszania protokołu HTTPS. Używa on również hosta przychodzącego do generowania adresu URL HTTPS.
• Usługa App Service ma ustawienie koligacji ARR, aby włączyć trwałe sesje, 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. Plik cookie Domain jest ustawiony na hosta przychodzącego.
• Usługa App Service udostępnia funkcje 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 powoduje również włączenie przekierowania 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, contoso.com aby rozpoznać adres IP usługi Application Gateway. W związku z tym odbiera żądanie z contoso.com przeglądarki i jest skonfigurowany do przekazywania tego żądania do adresu IP, który contoso.azurewebsites.net jest rozpoznawany: jest to ostateczna usługa zaplecza dla żądanego hosta. W takim przypadku jednak usługa App Service nie rozpoznaje domeny niestandardowej contoso.com 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, aby ta konfiguracja działała, jest zastąpienie lub ponowne zapisywanie Host nagłówka żą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 dla contoso.azurewebsites.net elementu 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 z hostem puli zaplecza. Usługa Azure Front Door nawet domyślnie to robi.

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 do contoso.com zwrotnego serwera proxy.
2. Zwrotny serwer proxy ponownie zapisuje nazwę contoso.azurewebsites.net hosta 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 przychodzącego contoso.azurewebsites.net hosta, 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 pod adresem 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 możliwości uwierzytelniania i autoryzacji usługi App Service. Ten diagram ilustruje problem:

1. Przeglądarka wysyła żądanie do contoso.com zwrotnego serwera proxy.
2. Zwrotny serwer proxy ponownie zapisuje nazwę contoso.azurewebsites.net hosta na żądanie do aplikacji internetowej zaplecza (lub podobnej domeny domyślnej dla innej usługi).
3. Aplikacja generuje bezwzględny adres URL przekierowania oparty na nazwie przychodzącego contoso.azurewebsites.net hosta, 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 takim 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 Domain atrybutu 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 ustawienie koligacji ARR usługi App Service. Ten diagram ilustruje problem:

1. Przeglądarka wysyła żądanie do contoso.com zwrotnego serwera proxy.
2. Zwrotny serwer proxy ponownie zapisuje nazwę contoso.azurewebsites.net hosta 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 przychodzącego contoso.azurewebsites.net hosta. Przeglądarka przechowuje plik cookie dla tej konkretnej domeny, a nie contoso.com domenę, 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 azurewebsites.net nazwy hosta 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 regularne CNAME lub A rekordy. (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 bezpłatna W tym przypadku nie można użyć zarządzanego certyfikatu usługi App Service, ponieważ wymaga ona, aby rekord DNS domeny był rozpoznawany bezpośrednio w usłudze App Service, a nie odwrotny serwer proxy).

Podobnie, jeśli używasz aplikacji Spring Apps, możesz użyć domeny niestandardowej dla aplikacji , aby uniknąć używania azuremicroservices.io nazwy hosta. 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 usługą 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 azure-api.net nazwy hosta. 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, takich jak 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 forwarded na przykład nagłówków lub X-Forwarded-Host .

Konfiguracja zwrotnego serwera proxy

Po zdefiniowaniu zaplecza w odwrotnym serwerze proxy nadal można użyć domyślnej domeny 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 Dns z podziałem na horyzoncie).

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 usługi Application Gateway jako zwrotnego serwera proxy, możesz upewnić się, że oryginalna nazwa hosta jest zachowywana, wyłączając ustawienie Przesłoń z nową nazwą hosta w ustawieniu HTTP zaplecza. Spowoduje to wyłączenie zarówno opcji Wybierz nazwę hosta z adresu zaplecza, jak i zastąpienie przy użyciu określonej nazwy domeny. (Oba te ustawienia zastępują nazwę hosta). We właściwościach usługi Azure Resource Manager dla usługi Application Gateway ta konfiguracja odpowiada ustawieniu hostName właściwości na null i pickHostNameFromBackendAddress na false.

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ć opcję Wybierz nazwę hosta z ustawień protokołu HTTP zaplecza i 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 uniknąć zastępowania nazwy hosta, pozostawiając nagłówek hosta zaplecza pusty w definicji puli zaplecza. W definicji usługi Resource Manager puli zaplecza ta konfiguracja odpowiada ustawieniu backendHostHeader .null

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

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 serviceUrl wartości definicji usługi Resource Manager interfejsu API).

Możesz wymusić użycie nazwy hosta żądania przychodzącego przez usługę API Management, dodając inbound zasady Ustaw nagłówek HTTP 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
• Aplikacje Spring
• Application Gateway
• Azure Front Door
• API Management

Powiązane zasoby

• Sieć o zerowym zaufaniu 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 w przedsiębiorstwie przy użyciu środowiska App Services Environment