Modifications de Nginx 1.26 dans Apigee Edge 4.53.00

Présentation des modifications apportées à Nginx 1.26

Avec le lancement de Nginx 1.26, plusieurs modifications importantes ont été introduites pour améliorer la sécurité et garantir la conformité avec les normes HTTP. Voici les principales mises à jour:

Traitement des espaces blancs dans les noms et valeurs des en-têtes

Pour améliorer la sécurité, le respect de la norme RFC 7230 a été renforcé, en particulier concernant 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 de contrebande de requêtes consiste à envoyer des requêtes HTTP avec les 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 contenant les deux en-têtes. Si une telle requête est envoyée, Nginx renvoie une erreur 400 Bad Request.

Algorithmes de chiffrement compatibles

La liste des algorithmes de chiffrement compatibles avec les requêtes liées au nord est susceptible de changer avec cette version. Vous pouvez vérifier les algorithmes de chiffrement compatibles avec OpenSSL sur votre hôte de routeur pour obtenir la liste à jour des algorithmes de chiffrement disponibles.

Tailles de clé compatibles

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 à sens unique et bidirectionnelles pour les requêtes northbound.

Annexe

Espaces blancs dans les en-têtes

Voici les trois principales modifications apportées :

  1. Certains noms d'en-tête précédemment autorisés ne sont plus autorisés par Nginx 1.26. Les requêtes contenant ces en-têtes génèrent une erreur 400 Bad Request.
  2. Certaines valeurs d'en-tête auparavant autorisées sont désormais interdites par Nginx 1.26. Les requêtes contenant ces en-têtes génèrent également une erreur 400 Bad Request.
  3. Certains en-têtes qui étaient auparavant acceptés par Nginx, mais qui provoquaient des erreurs en aval dans le processeur de messages, sont désormais rejeté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. Il ne s'agit que d'exemples, et la liste n'est pas 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êtes autorisés dans Nginx 1.20.1, mais désormais interdits dans Nginx 1.26.

Scénario Exemples de noms d'en-tête
Caractère de contrôle au début, à la fin ou entre le 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 en début et en fin de nom d'en-tête {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Combinaison initiale et finale de HTAB, WS dans le nom de l'en-tête {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
NewLine (\n) entre le nom d'en-tête suivi immédiatement de WS ou d'une série de WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) entre le nom d'en-tête suivi immédiatement de la fonction HTAB ou d'une série de HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Retour chariot (\r) Saut de ligne (\n) entre le nom de l'en-tête et immédiatement suivi d'un HTAB ou d'une série de HTAB {"En-tête\r\n\t69", "Valeur69"}
{"En-tête\r\n\t\t70", "Valeur70"}
Retour chariot (\r) NewLine (\n) entre le nom d'en-tête, suivi immédiatement de WS ou d'une série de WS {"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 interdites dans Nginx 1.26.

Scénario Exemples
\r\n ou une combinaison de \r\n avec WS ou HTAB autorisée 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é entre HEADERVALUE {"Header61", "Value\n 61Multiline"},
{"Header62", "Value\n 63Multiline"},
{"Header65", "Valeur\n\t65"},
{"Header66", "Valeur\n\t\t66"},
{"Header67", "Value\n 67"},
{"Header68", "Valeur\n 68"}

Modification de la réponse d'échec HTTP

Cette section couvre les en-têtes autorisés par l'ancien serveur Nginx, mais rejetés par le processeur de messages en amont, générant ainsi un code d'état 400. Toutefois, dans Nginx 1.26, ces en-têtes entraînent des échecs directement dans 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 reste 400. Cependant, 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 sont rejetées par Nginx lui-même. Le client de l'API recevra une réponse d'erreur 400 avec un message d'erreur Nginx dans le corps.

 {"Header 5", "Value5"},
{"En-tête\t14", "Valeur14"},
{"Header\t 32", "Value32"},
{"En-tête \t33", "Valeur33"},
{"Header- 36", "Value36"},
{"Header-\t40", "Valeur40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}