Nginx 1.26-Änderungen in Apigee Edge 4.53.01

Änderungen in Nginx 1.26

Mit der Veröffentlichung von Nginx 1.26 wurden mehrere wichtige Änderungen eingeführt, um die Sicherheit zu verbessern und die Einhaltung von HTTP-Standards zu gewährleisten. Hier sind die wichtigsten Änderungen:

Umgang mit Leerzeichen in Headernamen und ‑werten

Zur Verbesserung der Sicherheit wurde die Einhaltung von RFC 7230 verstärkt, insbesondere in Bezug auf die Verarbeitung von Leerzeichen in Headern. Weitere Informationen zu diesen Änderungen finden Sie im Anhang.

Umgang mit Content-Length- und Transfer-Encoding-Headern

Eine der gängigen Techniken, die bei Angriffen durch Schmuggeln von Anfragen verwendet werden, besteht darin, HTTP-Anfragen mit Headern vom Typ Content-Length und Transfer-Encoding zu senden. Apigee Edge war bereits gegen solche Angriffe geschützt, aber Nginx blockiert jetzt explizit Anfragen, die beide Header enthalten. Wenn eine solche Anfrage gesendet wird, antwortet Nginx mit dem Fehler 400 Bad Request.

Unterstützte Chiffren

Die Liste der unterstützten Chiffren für Northbound-Anfragen kann sich mit dieser Version ändern. Sie können die von OpenSSL auf Ihrem Router-Host unterstützten Chiffren prüfen, um die aktualisierte Liste der verfügbaren Chiffren zu erhalten.

Unterstützte Schlüsselgrößen

Bisher wurden RSA-, DSA- und DH-Schlüssel, die kleiner als 2.048 Bit sind, und ECC-Schlüssel, die kleiner als 224 Bit sind, standardmäßig akzeptiert. Mit diesem Update sind solche Schlüssel jedoch nicht mehr für unidirektionale und bidirektionale TLS-Verbindungen für Northbound-Anfragen zulässig.

Anhang

Leerzeichen in Headern

Es gibt drei wesentliche Änderungen:

  1. Bestimmte Headernamen, die zuvor zulässig waren, sind in Nginx 1.26 nicht mehr zulässig. Anfragen mit diesen Headern führen zu einem 400 Bad Request-Fehler.
  2. Bestimmte Header-Werte, die zuvor zulässig waren, sind in Nginx 1.26 nicht mehr zulässig. Anfragen mit diesen Headern führen ebenfalls zu einem 400 Bad Request-Fehler.
  3. Einige Header, die zuvor von Nginx akzeptiert wurden, aber nachgelagerte Fehler im Message Processor verursacht haben, werden jetzt direkt von Nginx abgelehnt. Obwohl diese Header weiterhin zu API-Fehlern führen, ändern sich die HTTP-Fehlermeldungen.

Im Abschnitt unten finden Sie Beispiele für verschiedene Header-Namen und Header-Werte, die nicht zulässig sind. Hierbei handelt es sich lediglich um Beispiele. Es besteht kein Anspruch auf Vollständigkeit. Es wird empfohlen, die Richtlinien von RFC 7230 für Header einzuhalten.

Änderungen an Headernamen

In diesem Abschnitt sind verschiedene Headernamen aufgeführt, die in Nginx 1.20.1 zulässig waren, in Nginx 1.26 jedoch nicht mehr.

Szenario Beispiele für Headernamen
Steuerzeichen am Anfang, am Ende oder zwischen den Zeichen des Headernamens { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Führende und nachgestellte Leerzeichen im Headernamen {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Führende und nachfolgende HTAB im Headernamen {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Kombination aus führenden und nachgestellten HTAB- und WS-Zeichen im Headernamen {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
NewLine (\n) zwischen dem Headernamen, gefolgt von einem oder mehreren Leerzeichen {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) zwischen dem Headernamen, gefolgt von HTAB oder einer Reihe von HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Zeilenumbruch (\r) und Zeilenvorschub (\n) zwischen dem Headernamen, gefolgt von einem oder mehreren horizontalen Tabulatoren (HTAB) {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Zeilenumbruch (\r) und Zeilenvorschub (\n) zwischen dem Headernamen, gefolgt von einem oder mehreren Leerzeichen {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Änderungen bei Headerwerten

In diesem Abschnitt werden verschiedene Headerwerte aufgeführt, die in Nginx 1.20.1 zulässig, in Nginx 1.26 jedoch unzulässig waren.

Szenario Beispiele
\r\n oder eine Kombination aus \r\n mit WS oder HTAB zwischen HEADERVALUE ist zulässig. {"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 oder Kombination aus \n mit WS oder HTAB zwischen HEADERVALUE zulässig {"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"}

Änderung der HTTP-Fehlerantwort

In diesem Abschnitt werden Header behandelt, die vom alten Nginx zugelassen, aber vom Upstream-Nachrichtenprozessor abgelehnt wurden, was zu einem 400-Statuscode führte. In Nginx 1.26 führen solche Headern jedoch direkt zu Fehlern in Nginx, sodass die Anfrage nicht an den Message Processor weitergeleitet wird.

Für Clients, die solche Header senden, bleibt der HTTP-Statuscode 400. Der HTTP-Antworttext kann sich jedoch ändern, da der Fehler jetzt von Nginx anstelle des Message Processors generiert wird.

Szenario Beispiele
HTAB oder WS zwischen HEADERNAME

Der Message Processor lehnt solche Anfragen ab. Mit Nginx 1.26 werden diese Anfragen von Nginx selbst abgelehnt. Der API-Nutzer erhält eine 400-Fehlerantwort mit einer Nginx-Fehlermeldung im Text.

 {"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"}