Cambios en Nginx 1.26 en Apigee Edge 4.53.01

Descripción general de los cambios en Nginx 1.26

Con el lanzamiento de Nginx 1.26, se introdujeron varios cambios importantes para mejorar la seguridad y garantizar el cumplimiento de los estándares HTTP. Estas son las actualizaciones clave:

Manejo de espacios en blanco en nombres y valores de encabezados

Para mejorar la seguridad, se reforzó el cumplimiento de RFC 7230, en especial en lo que respecta al manejo de espacios en blanco en los encabezados. En el Apéndice, encontrarás más detalles sobre estos cambios.

Control de los encabezados Content-Length y Transfer-Encoding

Una de las técnicas comunes que se usan en los ataques de contrabando de solicitudes consiste en enviar solicitudes HTTP con encabezados Content-Length y Transfer-Encoding. Si bien Apigee Edge ya estaba protegido contra este tipo de ataques, Nginx ahora bloquea explícitamente las solicitudes que contienen ambos encabezados. Si se envía una solicitud de este tipo, Nginx responderá con un error 400 Bad Request.

Algoritmos de cifrado admitidos

La lista de algoritmos de encriptación admitidos para las solicitudes de salida puede cambiar con esta versión. Puedes verificar los algoritmos de cifrado compatibles con OpenSSL en el host del router para obtener la lista actualizada de algoritmos de cifrado disponibles.

Tamaños de clave admitidos

Anteriormente, se aceptaban de forma predeterminada las claves RSA, DSA y DH menores de 2048 bits, y las claves ECC menores de 224 bits. Sin embargo, con esta actualización, ya no se permitirán esas claves para las conexiones TLS unidireccionales y bidireccionales para las solicitudes de extremo ascendente.

Apéndice

Espacio en blanco en los encabezados

Hay tres cambios principales:

  1. Nginx 1.26 ya no permite ciertos nombres de encabezado que antes sí se permitían. Las solicitudes con estos encabezados generarán un error de 400 Bad Request.
  2. Nginx 1.26 ya no permite ciertos valores de encabezado que antes sí se permitían. Las solicitudes con estos encabezados también generarán un error de 400 Bad Request.
  3. Algunos encabezados que antes aceptaba Nginx, pero que causaban fallas en el procesador de mensajes, ahora son rechazados directamente por Nginx. Si bien estos encabezados seguirán provocando errores de API, los mensajes de error HTTP cambiarán.

En la siguiente sección, se proporcionan ejemplos de varios nombres y valores de encabezado que no se permiten. Estos son solo algunos ejemplos; la lista no pretende ser exhaustiva. Se recomienda cumplir con los lineamientos de RFC 7230 para los encabezados.

Cambios en los nombres de los encabezados

En esta sección, se enumeran varios nombres de encabezado que se permitían en Nginx 1.20.1, pero que ahora no se permiten en Nginx 1.26.

Situación Ejemplos de nombres de encabezados
Carácter de control al principio, al final o entre el nombre del encabezado { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Espacios en blanco iniciales y finales en el nombre del encabezado {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
HTAB inicial y final en el nombre del encabezado {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Combinación de HTAB y WS inicial y final en el nombre del encabezado {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Nueva línea (\n) entre el nombre del encabezado seguido inmediatamente de WS o una serie de WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Nueva línea (\n) entre el nombre del encabezado seguido inmediatamente de HTAB o una serie de HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Retorno de carro (\r) y salto de línea (\n) entre el nombre del encabezado seguido inmediatamente de HTAB o una serie de HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Retorno de carro (\r) Salto de línea (\n) entre el nombre del encabezado seguido inmediatamente de WS o una serie de WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Cambios en los valores de encabezado

En esta sección, se muestran varios valores de encabezado que se permitían en Nginx 1.20.1, pero no en Nginx 1.26.

Situación Ejemplos
\r\n o combinación de \r\n con WS o HTAB permitidos 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 o combinación de \n con WS o HTAB permitidos 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"}

Cambio en la respuesta de error HTTP

En esta sección, se abordan los encabezados que permitía el antiguo Nginx, pero que rechazó el procesador de mensajes upstream, lo que generó un código de estado 400. Sin embargo, en Nginx 1.26, estos encabezados provocan errores directamente en Nginx, lo que impide que la solicitud se reenvíe al procesador de mensajes.

Para los clientes que envían esos encabezados, el código de estado HTTP seguirá siendo 400. Sin embargo, el cuerpo de la respuesta HTTP puede cambiar, ya que Nginx generará la falla en lugar del procesador de mensajes.

Situación Ejemplos
HTAB o WS entre HEADERNAME

El procesador de mensajes rechaza esas solicitudes. Con Nginx 1.26, Nginx rechazará estas solicitudes. El consumidor de la API recibirá una respuesta de error 400 con un mensaje de error de Nginx en el cuerpo.

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