Zmiany w Nginx 1.26 w Apigee Edge 4.53.01

Omówienie zmian w Nginx 1.26

Wraz z wersją Nginx 1.26 wprowadziliśmy kilka ważnych zmian, które zwiększają bezpieczeństwo i zapewniają zgodność ze standardami HTTP. Oto najważniejsze zmiany:

Obsługa białych znaków w nazwach i wartościach nagłówków

Aby zwiększyć bezpieczeństwo, wzmocniliśmy zgodność ze standardem RFC 7230, zwłaszcza w zakresie obsługi białych znaków w nagłówkach. Więcej informacji o tych zmianach znajdziesz w dodatku.

Obsługa nagłówków Content-Length i Transfer-Encoding

Jedna z popularnych technik stosowanych w atakach typu request smuggling polega na wysyłaniu żądań HTTP z nagłówkami Content-Length i Transfer-Encoding. Apigee Edge był już zabezpieczony przed takimi atakami, ale Nginx teraz jawnie blokuje żądania zawierające oba nagłówki. Jeśli takie żądanie zostanie wysłane, Nginx odpowie błędem 400 Nieprawidłowe żądanie.

Obsługiwane szyfry

Lista obsługiwanych mechanizmów szyfrowania w przypadku żądań wychodzących może się zmienić w tej wersji. Aby uzyskać zaktualizowaną listę dostępnych szyfrów, możesz sprawdzić szyfry obsługiwane przez OpenSSL na hoście routera.

Obsługiwane rozmiary kluczy

Wcześniej domyślnie akceptowane były klucze RSA, DSA i DH o rozmiarze mniejszym niż 2048 bitów oraz klucze ECC o rozmiarze mniejszym niż 224 bity. Po wprowadzeniu tej zmiany takie klucze nie będą już dozwolone w przypadku połączeń TLS w jedną i dwie strony w przypadku żądań wychodzących.

Dodatek

Odstępy w nagłówkach

Oto 3 główne zmiany:

  1. Niektóre nazwy nagłówków, które były wcześniej dozwolone, są teraz niedozwolone w NGINX 1.26. Żądania z tymi nagłówkami będą powodować błąd 400 Nieprawidłowe żądanie.
  2. Niektóre wartości nagłówka, które były wcześniej dozwolone, są teraz niedozwolone w Nginx 1.26. Żądania z tymi nagłówkami również będą powodować błąd 400 Nieprawidłowe żądanie.
  3. Niektóre nagłówki, które były wcześniej akceptowane przez Nginx, ale powodowały błędy w procesorze wiadomości, są teraz odrzucane bezpośrednio przez Nginx. Chociaż te nagłówki nadal powodują błędy interfejsu API, komunikaty o błędach HTTP ulegną zmianie.

W sekcji poniżej znajdziesz przykłady różnych nazw i wartości nagłówków, które są niedozwolone. Są to jedynie przykłady i nie stanowią one wyczerpującej listy. Zalecamy przestrzeganie wytycznych dotyczących nagłówków określonych w dokumencie RFC 7230.

Zmiany nazw nagłówków

W tej sekcji znajdziesz listę nazw nagłówków, które były dozwolone w Nginx 1.20.1, ale są niedozwolone w Nginx 1.26.

Scenariusz Przykłady nazw nagłówków
Znak sterujący na początku, na końcu lub w środku nazwy nagłówka { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Odstępy na początku i na końcu nazwy nagłówka {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Wiodący i końcowy znak HTAB w nazwie nagłówka {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Wiodąca i końcowa kombinacja HTAB, WS w nazwie nagłówka {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Znaki nowego wiersza (\n) między nazwą nagłówka a znakami WS lub serią znaków WS. {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
znak nowego wiersza (\n) między nazwą nagłówka, po którym bezpośrednio następuje HTAB lub seria HTAB; {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Przejście do nowej linii (\r) lub znak nowego wiersza (\n) między nazwą nagłówka, po którym bezpośrednio następuje HTAB lub seria HTAB. {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Przejście do nowej linii (\r) lub znak nowego wiersza (\n) między nazwą nagłówka, po którym bezpośrednio następuje WS lub seria WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Zmiany wartości nagłówków

Ta sekcja zawiera różne wartości nagłówków, które były dozwolone w Nginx 1.20.1, ale niedozwolone w Nginx 1.26.

Scenariusz Przykłady
\r\n lub kombinacja \r\n z WS lub HTAB dozwolonymi między HEADERVALUE {"Header47", "Value47\r\n MultiLine"},
{"Header48", "Value48\r\n MultiLine"},
{"Header49b", "Value49b\r\n \r\nMultiLine"},
{"Header50", "Value50 \r\n MultiLine"},
{"Header51", "Value51\r\n\tMultiLine"},
{"Header52", "Value52\r\n\t\tMultiLine"},
{"Header53", "Value53\t\r\n\tMultiLine"}
\n lub kombinacja \n z WS lub HTAB dozwolonymi między HEADERVALUE {"Header61", "Value\n 61Multiline"},
{"Header62", "Value\n 63Multiline"},
{"Header65", "Value\n\t65"},
{"Header66", "Value\n\t\t66"},
{"Header67", "Value\n 67"},
{"Header68", "Value\n 68"}

Zmiana odpowiedzi HTTP w przypadku błędu

Ta sekcja obejmuje nagłówki, które były dozwolone przez starego Nginx, ale odrzucone przez procesor wiadomości upstream, co spowodowało zwrócenie kodu stanu 400. W NGINX 1.26 takie nagłówki powodują jednak błędy bezpośrednio w NGINX, co uniemożliwia przekazanie żądania do procesora wiadomości.

W przypadku klientów, którzy wysyłają takie nagłówki, kod stanu HTTP pozostanie 400. Treść odpowiedzi HTTP może się jednak zmienić, ponieważ błąd będzie teraz generowany przez Nginx zamiast przez procesor wiadomości.

Scenariusz Przykłady
HTAB lub WS między HEADERNAME

Procesor wiadomości odrzuca takie żądania. W przypadku Nginx 1.26 żądania te będą odrzucane przez sam serwer Nginx. Klient interfejsu API otrzyma odpowiedź o błędzie 400 z komunikatem o błędzie Nginx w treści.

 {"Header 5", "Value5"},
{"Header\t14", "Value14"},
{"Header\t 32", "Value32"},
{"Header \t33", "Value33"},
{"Header- 36", "Value36"},
{"Header-\t40", "Value40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}