Änderungen bei Nginx 1.26 in Apigee Edge 4.53.00

Übersicht über die Änderungen bei 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. Im Folgenden sind die wichtigsten Aktualisierungen aufgeführt:

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.

Verarbeitung von 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 ausdrücklich 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 und 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 zum Fehler 400 Bad Request.
  2. Bestimmte Headerwerte, die zuvor zulässig waren, werden jetzt von Nginx 1.26 nicht zugelassen. Anfragen mit diesen Headern führen ebenfalls zum Fehler 400 Bad Request.
  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.

Der folgende Abschnitt enthält Beispiele für verschiedene Headernamen und -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, jetzt aber in Nginx 1.26 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, Wert4 }
Führende & Nachstehendes 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"}
Führende & nachgestellte Kombination aus HTAB und WS im Headernamen {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
NewLine (\n) zwischen Headernamen, gefolgt von WS oder einer Reihe von WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) zwischen dem Titelnamen gefolgt von HTAB oder einer Reihe von HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Zeilenvorschub (\r) und Zeilenumbruch (\n) zwischen dem Headernamen, gefolgt unmittelbar von HTAB oder einer Reihe von HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Wert70"}
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

Dieser Abschnitt zeigt verschiedene Headerwerte, die in Nginx 1.20.1 zulässig waren, in Nginx 1.26 jedoch nicht.

Szenario Beispiele
\r\n oder Kombination aus\r\n mit WS oder HTAB ist in folgendem Zeitraum zulässig: 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 oder eine Kombination aus \n mit WS oder HTAB ist zwischen HEADERVALUE zulässig. {"Header61", "Wert\n 61Mehrzeiliger Text"},
{"Header62", "Wert\n 63Mehrzeiliger Text"},
{"Header65", "Wert\n\t65"},
{"Header66", "Wert\n\t\t66"},
{"Header67", "Wert\n 67"},
{"Header68", "Wert\n 68"}

Änderung in der HTTP-Fehlerantwort

In diesem Abschnitt werden Header behandelt, die von der alten Nginx zugelassen, aber vom Upstream-Nachrichtenprozessor abgelehnt wurden, was zu einem 400-Statuscode 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 Nachrichtenprozessor 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.

 {"Überschrift 5", "Wert5"},
{"Überschrift\t14", "Wert14"},
{"Überschrift\t 32", "Wert32"},
{"Überschrift \t33", "Wert33"},
{"Header- 36", "Value36"},
{"Header-\t40", "Wert40"},
{"Header 4a", "Value4a"},
{"Überschrift\t 59", "Wert59"},
{"Header\t 60", "Value60"}