Zmiany w Nginx 1.26 w Apigee Edge 4.53.00

Omówienie zmian w Nginx 1.26

Wraz z premierą 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:

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

Aby poprawić bezpieczeństwo, zwiększyliśmy też zgodność ze standardem RFC 7230, co dotyczy zwłaszcza 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

Lista obsługiwanych mechanizmów szyfrowania dla żądań w kierunku północnym może się zmienić w tej wersji. Aby uzyskać zaktualizowaną listę dostępnych szyfrów, sprawdź 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 tej aktualizacji takie klucze nie będą już dozwolone zarówno w przypadku jednokierunkowych, jak i dwukierunkowych połączeń TLS w przypadku żądań kierowanych na północ.

Dodatek

Odstępy 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 przez 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 przez Nginx 1.26. Żądania z tymi nagłówkami będą także powodować występowanie błędu 400 Bad Request (Nieprawidłowe żądanie).
  3. Niektóre nagłówki, które były wcześniej akceptowane przez Nginx, ale spowodowały błędy w procesie przetwarzania 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 nagłówków i wartości nagłówków. Są to jedynie przykłady i nie są one wyczerpujące. Zalecamy przestrzeganie wytycznych RFC 7230 dotyczących nagłówków.

Zmiany nazw nagłówków

W tej sekcji znajdziesz różne nazwy nagłówków, które były dozwolone w Nginx 1.20.1, ale teraz niedozwolone w Nginx 1.26.

Scenariusz Przykłady nazw nagłówków
znak kontrolny na początku, końcu lub w środku nazwy nagłówka; { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Prowadzenie i końcowa spacja w nazwie 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 ciąg znaków WS lub serii WS. {"Header\n 57Mutiline", "Value57"}
{"Nagłówek\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"}
Powrót karetki (\r) NewLine (\n) między nazwą nagłówka, po którym następuje znak HTAB lub serię HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Powrót karetki (\r) NewLine (\n) między nazwą nagłówka, po którym następuje ciąg znaków WS lub serii WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Zmiany wartości nagłówka

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

Scenariusz Przykłady
YPM\n lub kombinacji wartości \r\n z WS lub HTAB, między 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"}
\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 przekazanie żądania do procesora wiadomości.

W przypadku klientów wysyłających takie nagłówki kod stanu HTTP będzie nadal miał wartość 400. Jednak treść odpowiedzi HTTP może się zmienić, ponieważ błąd będzie generowany przez Nginx, a nie przez procesor wiadomości.

Scenariusz Przykłady
HTAB lub WS między nagłówkiem NAZWA_NAGŁÓWKA

Procesor wiadomości odrzuca takie żądania. W wersji Nginx 1.26 żądania te będą odrzucane przez samą organizację Nginx. Użytkownik interfejsu API otrzyma odpowiedź z błędem 400 z komunikatem o błędzie Nginx w sekcji treści.

 {"Header 5", "Wartość5"},
{"Header\t14", "Wartość14"},
{"Header\t 32", "Value32"},
{"Header \t33", "Wartość33"},
{"Header- 36", "Value36"},
{"Header-\t40", "Value40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}