Modifications apportées à Nginx 1.26 dans Apigee Edge 4.53.01

Présentation des modifications apportées à Nginx 1.26

Avec la sortie de Nginx 1.26, plusieurs modifications importantes ont été apportées pour améliorer la sécurité et assurer la conformité aux normes HTTP. Voici les principales modifications :

Gestion des espaces blancs dans les noms et valeurs d'en-tête

Pour améliorer la sécurité, le respect de la norme RFC 7230 a été renforcé, en particulier en ce qui concerne la gestion des espaces dans les en-têtes. Pour en savoir plus sur ces modifications, consultez l'annexe.

Gestion des en-têtes Content-Length et Transfer-Encoding

L'une des techniques courantes utilisées dans les attaques par trafic de requêtes consiste à envoyer des requêtes HTTP avec des en-têtes Content-Length et Transfer-Encoding. Bien qu'Apigee Edge soit déjà protégé contre de telles attaques, Nginx bloque désormais explicitement les requêtes qui contiennent les deux en-têtes. Si une telle requête est envoyée, Nginx répondra par une erreur 400 Bad Request.

Algorithmes de chiffrement acceptés

La liste des codes secrets compatibles pour les requêtes Northbound peut changer avec cette version. Vous pouvez vérifier les algorithmes de chiffrement compatibles avec OpenSSL sur l'hôte de votre routeur pour obtenir la liste à jour des algorithmes de chiffrement disponibles.

Tailles de clés acceptées

Auparavant, les clés RSA, DSA et DH inférieures à 2 048 bits, et les clés ECC inférieures à 224 bits étaient acceptées par défaut. Toutefois, avec cette mise à jour, ces clés ne seront plus autorisées pour les connexions TLS unidirectionnelles et bidirectionnelles pour les requêtes Northbound.

Annexe

Espaces dans les en-têtes

Voici les trois principaux changements :

  1. Certains noms d'en-tête qui étaient auparavant autorisés ne le sont plus avec Nginx 1.26. Les requêtes comportant ces en-têtes généreront une erreur 400 Bad Request.
  2. Certaines valeurs d'en-tête qui étaient auparavant autorisées ne le sont plus par Nginx 1.26. Les requêtes comportant ces en-têtes généreront également une erreur 400 (requête incorrecte).
  3. Certains en-têtes qui étaient auparavant acceptés par Nginx, mais qui entraînaient des échecs en aval dans le processeur de messages, sont désormais refusés directement par Nginx. Bien que ces en-têtes entraînent toujours des échecs d'API, les messages d'échec HTTP changeront.

La section ci-dessous fournit des exemples de noms et de valeurs d'en-tête non autorisés. Les questions ci-dessous ne sont fournies qu'à titre d'exemple. Il ne s'agit pas d'une liste exhaustive. Il est recommandé de respecter les consignes de la RFC 7230 pour les en-têtes.

Modifications apportées aux noms d'en-tête

Cette section liste différents noms d'en-tête qui étaient autorisés dans Nginx 1.20.1, mais qui ne le sont plus dans Nginx 1.26.

Scénario Exemples de noms d'en-tête
Caractère de contrôle au début, à la fin ou au milieu du nom de l'en-tête { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Espaces de début et de fin dans le nom de l'en-tête {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
HTAB de début et de fin dans le nom de l'en-tête {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Combinaison de HTAB et WS en début et en fin du nom de l'en-tête {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Un caractère de nouvelle ligne (\n) entre le nom de l'en-tête, suivi immédiatement d'un ou plusieurs espaces {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Un caractère de nouvelle ligne (\n) entre le nom de l'en-tête et un ou plusieurs caractères HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Retour chariot (\r) ou saut de ligne (\n) entre le nom de l'en-tête et un ou plusieurs caractères HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Retour chariot (\r) ou saut de ligne (\n) entre le nom de l'en-tête, suivi immédiatement d'un ou plusieurs espaces {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Modifications des valeurs d'en-tête

Cette section présente différentes valeurs d'en-tête qui étaient autorisées dans Nginx 1.20.1, mais qui ne le sont plus dans Nginx 1.26.

Scénario Exemples
\r\n ou combinaison de \r\n avec WS ou HTAB autorisés entre 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 ou combinaison de \n avec WS ou HTAB autorisée entre 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"}

Modification de la réponse d'échec HTTP

Cette section couvre les en-têtes qui étaient autorisés par l'ancien Nginx, mais qui ont été rejetés par le processeur de messages en amont, ce qui a entraîné un code d'état 400. Toutefois, dans Nginx 1.26, ces en-têtes entraînent des échecs directement au niveau de Nginx, ce qui empêche la requête d'être transférée au processeur de messages.

Pour les clients qui envoient de tels en-têtes, le code d'état HTTP restera 400. Toutefois, le corps de la réponse HTTP peut changer, car l'échec sera désormais généré par Nginx au lieu du processeur de messages.

Scénario Exemples
HTAB ou WS entre HEADERNAME

Le processeur de messages rejette ces requêtes. Avec Nginx 1.26, ces requêtes seront rejetées par Nginx lui-même. Le consommateur de l'API recevra une réponse d'erreur 400 avec un message d'erreur Nginx dans le corps.

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