Nginx 1.26 cambia en Apigee Edge 4.53.00

Descripción general de los cambios de Nginx 1.26

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

Manejo de espacios en blanco en los nombres y valores de los encabezados

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

Control de encabezados Content-Length y Transfer-Encoding

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

Algoritmos de cifrado compatibles

Es posible que la lista de algoritmos de cifrado admitidos para las solicitudes orientadas al norte cambie 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 compatibles

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

Apéndice

Espacios en blanco en los encabezados

Hay tres cambios principales:

  1. Nginx 1.26 ahora no permite ciertos nombres de encabezados que antes se permitían. Las solicitudes con estos encabezados generarán un error de solicitud incorrecta 400.
  2. Nginx 1.26 ahora no permite ciertos valores de encabezado que antes se permitían. Las solicitudes con estos encabezados también generarán un error de solicitud incorrecta 400.
  3. Nginx ahora rechaza directamente algunos encabezados que Nginx aceptaba anteriormente, pero que causaban fallas descendentes en el procesador de mensajes. Aunque estos encabezados aún generan fallas en la API, los mensajes de falla de HTTP cambiarán.

En la siguiente sección, se proporcionan ejemplos de varios nombres y valores de encabezado que no están permitidos. Estos son solo algunos ejemplos y es posible que no sean una lista 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 encabezados 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 comienzo, 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"}
Liderazgo y combinación final de HTAB, WS 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"}
El retorno de carro (\r) o la línea nueva (\n) entre el nombre del encabezado seguido inmediatamente de una HTAB o una serie de HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
El retorno de carro (\r) y la línea nueva (\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 permitidos en Nginx 1.20.1, pero no permitidos en Nginx 1.26.

Situación Ejemplos
Se permite \r\n o una combinación de \r\n con WS o HTAB 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 una combinación de \n con WS o HTAB 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 Nginx anterior, pero que el procesador de mensajes upstream rechazaba, lo que generaba un código de estado 400. Sin embargo, en Nginx 1.26, esos encabezados causan fallas 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 ahora 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"}