Zmiany w Nginx 1.30 w Apigee Edge 4.54.00

Omówienie zmian w Nginx

Apigee Edge for Private Cloud 4.54.00 obejmuje obowiązkową aktualizację do Nginx w wersji 1.30 na routerach Edge.

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

Obsługa odstępów w nazwach i wartościach nagłówków

Aby zwiększyć bezpieczeństwo, wzmocniliśmy zgodność z RFC 7230, zwłaszcza w zakresie obsługi odstępó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 powszechnych 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 teraz Nginx wyraźnie blokuje żądania zawierające oba te nagłówki. Jeśli takie żądanie zostanie wysłane, Nginx odpowie błędem 400 Nieprawidłowe żądanie.

Obsługiwane szyfry

W tej wersji może się zmienić lista obsługiwanych szyfrów w przypadku żądań wychodzących. 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. Jednak po tej aktualizacji takie klucze nie będą już dozwolone w przypadku połączeń TLS jednokierunkowych i dwukierunkowych w przypadku żądań wychodzących.

Dodatek

Odstępy w nagłówkach

Wprowadziliśmy 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łówków, które były wcześniej dozwolone, są teraz niedozwolone w Nginx 1.26. Żądania z tymi nagłówkami będą również 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 niedozwolonych nazw i wartości nagłówków. Są to tylko przykłady, a lista może nie być wyczerpująca. Zalecamy przestrzeganie wytycznych RFC 7230 dotyczących nagłówków.

Zmiany w nazwach nagłówków

W tej sekcji znajdziesz listę różnych nazw nagłówków, które były dozwolone w Nginx 1.20.1, ale są teraz 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 }
Wiodące i końcowe odstępy w nazwie nagłówka {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Wiodące i końcowe znaki HTAB w nazwie nagłówka {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Wiodące i końcowe połączenie znaków HTAB i WS w nazwie nagłówka {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Znak nowego wiersza (\n) w środku nazwy nagłówka, po którym bezpośrednio następuje znak WS lub seria znaków WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Znak nowego wiersza (\n) w środku nazwy nagłówka, po którym bezpośrednio następuje znak HTAB lub seria znaków HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Przejście do nowej linii (\r) i nowy wiersz (\n) w środku nazwy nagłówka, po którym bezpośrednio następuje znak HTAB lub seria znaków HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Przejście do nowej linii ( ) i nowy wiersz ( ) w środku nazwy nagłówka, po którym bezpośrednio następuje znak WS lub seria znaków WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Zmiany w wartościach nagłówków

W tej sekcji znajdziesz różne wartości nagłówków, które były dozwolone w Nginx 1.20.1, ale są niedozwolone w Nginx 1.26.

Scenariusz Przykłady
Znaki \r\n lub połączenie znaków \r\n z WS lub HTAB dozwolone w środku wartości 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"}
Znaki \n lub połączenie znaków \n z WS lub HTAB dozwolone w środku wartości 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 o błędzie HTTP

Ta sekcja obejmuje nagłówki, które były dozwolone w starej wersji Nginx, ale odrzucane przez procesor komunikatów, co powodowało zwracanie kodu stanu 400. Jednak w Nginx 1.26 takie nagłówki powodują błędy bezpośrednio w Nginx, co uniemożliwia przekazanie żądania do procesora komunikatów.

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, a nie przez procesor komunikatów.

Scenariusz Przykłady
Znaki HTAB lub WS w środku nazwy HEADERNAME

Procesor wiadomości odrzuca takie żądania. W Nginx 1.26 te żądania będą odrzucane przez sam 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"}