Zmiany w Nginx 1.26 w Apigee Edge 4.53.00

Omówienie zmian w Nginx 1.26

Wraz z wydaniem wersji Nginx 1.26 wprowadzono kilka ważnych zmian, które mają na celu zwiększenie bezpieczeństwa i zapewnienie zgodności ze standardami HTTP. Oto najważniejsze zmiany:

Obsługa spacji w nazwach i wartościach nagłówków

Aby zwiększyć bezpieczeństwo, zwiększyliśmy zgodność z standardem RFC 7230, zwłaszcza w zakresie obsługi odstępów w nagłówkach. Więcej informacji o tych zmianach znajdziesz w załączniku.

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

Jedną z popularnych technik stosowanych w atakach polegających na przemyceniu żądań jest wysyłanie żądań HTTP z nagłówkami Content-Length i Transfer-Encoding. Chociaż Apigee Edge było już chronione przed takimi atakami, Nginx blokuje teraz wyraźnie żądania zawierające oba nagłówki. Jeśli takie żądanie zostanie wysłane, Nginx odpowie błędem 400 Nieprawidłowe żądanie.

Obsługiwane szyfry

W tej wersji lista obsługiwanych szyfrów w przypadku żądań kierowanych do serwera może ulec zmianie. Aby uzyskać zaktualizowaną listę dostępnych szyfrów, możesz sprawdzić szyfry obsługiwane przez OpenSSL na hoście routera.

Obsługiwane rozmiary klucza

Wcześniej klucze RSA, DSA i DH o rozmiarze mniejszym niż 2048 bitów oraz klucze ECC o rozmiarze mniejszym niż 224 bitów były akceptowane domyślnie. Jednak po wprowadzeniu tej aktualizacji takie klucze nie będą już dozwolone w przypadku połączeń jednokierunkowych i dwukierunkowych TLS w przypadku żądań z zewnątrz.

Dodatek

Spacja w nagłówkach

Są to 3 główne zmiany:

  1. Niektóre nazwy nagłówków, które były wcześniej dozwolone, są teraz niedozwolone w wersji 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 wersji Nginx 1.26. Żądania z tymi nagłówkami również spowodują 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 dalszym przetwarzaniu 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 niedozwolonych nazw i wartości nagłówków. Są to jedynie przykłady i nie stanowią one wyczerpującej listy. Zalecamy przestrzeganie wytycznych RFC 7230 dotyczących nagłówków.

Zmiany nazw nagłówków

W tej sekcji znajdziesz listę różnych nazw nagłówków, które były dozwolone w wersji Nginx 1.20.1, ale są teraz zabronione w wersji Nginx 1.26.

Scenariusz Przykłady nazw nagłówków
znak kontrolny na początku, końcu lub w miejscu 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"}
Początkowy i końcowy znak tabulacji w nazwie nagłówka {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Początkowy i końcowy element HTAB, WS w nazwie nagłówka {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
NewLine (\n) między nazwą nagłówka, po którym następuje WS lub seria WS. {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Nowy wiersz (\n) między nazwą nagłówka, a zaraz po nim HTAB lub seria HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Przejście do nowej linii (\r) Nowa linia (\n) między nazwą nagłówka, bezpośrednio po której następuje HTAB lub seria HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Przejście do nowej linii (\r) Nowa linia (\n) między nazwą nagłówka, po której następuje natychmiast WS lub seria WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Zmiany wartości nagłówka

Ta sekcja zawiera różne wartości nagłówka, które były dozwolone w wersji Nginx 1.20.1, ale nie są dozwolone w wersji Nginx 1.26.

Scenariusz Przykłady
\r\n lub kombinacja \r\n z WS lub HTAB dozwolona 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 dozwolona 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 na błąd

Ta sekcja dotyczy nagłówków, które były dozwolone przez starą wersję Nginx, ale zostały odrzucone przez wcześniejszy procesor wiadomości, co spowodowało wyświetlenie kodu stanu 400. Jednak w wersji Nginx 1.26 takie nagłówki powodują błędy bezpośrednio w Nginx, uniemożliwiając przekierowanie żądania do procesora wiadomości.

W przypadku klientów, którzy wysyłają takie nagłówki, kod stanu HTTP pozostanie równy 400. Jednak treść odpowiedzi HTTP może się zmienić, ponieważ błąd będzie generowany przez Nginxa, a nie przez procesor wiadomości.

Scenariusz Przykłady
HTAB lub WS między HEADERNAME

Procesor wiadomości odrzuca takie żądania. W wersji Nginx 1.26 te żądania będą odrzucane przez Nginx. Użytkownik interfejsu API otrzyma odpowiedź z błędem 400 z komunikatem o błędzie Nginx w swoim 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"}