Änderungen bei Nginx 1.26 in Apigee Edge 4.53.00

Ä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 der HTTP-Standards zu gewährleisten. Hier sind die wichtigsten Änderungen:

Umgang mit Leerzeichen in Headernamen und ‑werten

Um die Sicherheit zu verbessern, wurde die Einhaltung von RFC 7230 verstärkt, insbesondere im Hinblick 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 bei Smuggling-Angriffen besteht darin, HTTP-Anfragen mit Content-Length- und Transfer-Encoding-Headern 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 Verschlüsselungsverfahren für Anfragen von Kunden zu Google kann sich mit dieser Version ändern. Sie können die von OpenSSL auf Ihrem Routerhost unterstützten Chiffren prüfen, um eine aktuelle Liste der verfügbaren Chiffren zu erhalten.

Unterstützte Schlüsselgrößen

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

Anhang

Leerzeichen in Überschriften

Es gibt drei Hauptä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 Headerwerte, 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 im Nachrichtenprozessor zu Fehlern geführt haben, werden jetzt direkt von Nginx abgelehnt. Auch wenn diese Header weiterhin zu API-Fehlern führen, ändern sich die HTTP-Fehlermeldungen.

Im folgenden Abschnitt finden Sie Beispiele für verschiedene Headernamen und Headerwerte, 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 aber nicht mehr zulässig sind.

Szenario Beispiele für Headernamen
Steuerzeichen am Anfang, Ende oder in der Mitte 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ührender und abschließender HTAB im Headernamen {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Anfangs- und Endkombination von HTAB und WS im Headernamen {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Ein Neulinenzeichen (\n) zwischen dem Headernamen und einem oder mehreren Leerzeichen {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Neue Zeile (\n) zwischen dem Headernamen und HTAB oder einer Reihe von HTABs {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Zeilenvorschub (\r) und Neuzeile (\n) zwischen dem Headernamen, gefolgt unmittelbar von HTAB oder einer Reihe von HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Zeilenvorschub (\r) und Zeilenumbruch (\n) zwischen dem Headernamen, gefolgt unmittelbar von WS oder einer Reihe von WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Änderungen an Headerwerten

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

Szenario Beispiele
\r\n oder eine Kombination aus \r\n mit WS oder HTAB ist zwischen HEADERVALUE 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 eine Kombination aus \n mit WS oder HTAB ist 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 beschrieben, die vom alten Nginx-Server zugelassen, aber vom Upstream-Nachrichten-Prozessor abgelehnt wurden, was zu einem Statuscode 400 führte. In Nginx 1.26 führen solche Header jedoch direkt zu Fehlern in Nginx, sodass die Anfrage nicht an den Message Processor weitergeleitet wird.

Bei Clients, die solche Header senden, bleibt der HTTP-Statuscode 400. Der HTTP-Antworttext kann sich jedoch ändern, da der Fehler jetzt von Nginx und nicht vom Message Processor generiert wird.

Szenario Beispiele
HTAB oder WS zwischen HEADERNAME

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

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