Mudanças do Nginx 1.26 no Apigee Edge 4.53.01

Visão geral das mudanças do Nginx 1.26

Com o lançamento do Nginx 1.26, várias mudanças importantes foram introduzidas para aumentar a segurança e garantir a conformidade com os padrões HTTP. Confira as principais atualizações:

Processamento de espaços em branco em nomes e valores de cabeçalho

Para melhorar a segurança, a adesão à RFC 7230 foi reforçada, principalmente em relação ao tratamento de espaços em branco nos cabeçalhos. Mais detalhes sobre essas mudanças podem ser encontrados no Apêndice.

Processamento de cabeçalhos Content-Length e Transfer-Encoding

Uma das técnicas comuns usadas em ataques de tráfego de solicitações envolve o envio de solicitações HTTP com cabeçalhos Content-Length e Transfer-Encoding. Embora o Apigee Edge já fosse protegido contra esses ataques, o Nginx agora bloqueia explicitamente as solicitações que contêm os dois cabeçalhos. Se uma solicitação desse tipo for enviada, o Nginx vai responder com um erro 400 Bad Request.

Criptografias compatíveis

A lista de criptografias compatíveis com solicitações de entrada pode mudar com esta versão. Confira as criptografias compatíveis com o OpenSSL no host do roteador para acessar a lista atualizada de criptografias disponíveis.

Tamanhos de chave compatíveis

Antes, as chaves RSA, DSA e DH menores que 2.048 bits e as chaves ECC menores que 224 bits eram aceitas por padrão. No entanto, com essa atualização, essas chaves não serão mais permitidas para conexões TLS unidirecionais e bidirecionais em solicitações northbound.

Apêndice

Espaço em branco nos cabeçalhos

Há três mudanças principais:

  1. Alguns nomes de cabeçalho que eram permitidos agora não são mais pelo Nginx 1.26. As solicitações com esses cabeçalhos vão resultar em um erro 400 Bad Request.
  2. Alguns valores de cabeçalho que eram permitidos agora são proibidos pelo Nginx 1.26. As solicitações com esses cabeçalhos também vão resultar em um erro 400 Bad Request.
  3. Alguns cabeçalhos que eram aceitos pelo Nginx, mas causavam falhas downstream no processador de mensagens, agora são rejeitados diretamente pelo Nginx. Embora esses cabeçalhos ainda causem falhas na API, as mensagens de falha HTTP vão mudar.

A seção abaixo mostra exemplos de vários nomes e valores de cabeçalho que não são permitidos. Estes são somente exemplos, e esta não é uma lista completa. Recomendamos seguir as diretrizes da RFC 7230 para cabeçalhos.

Mudanças nos nomes dos cabeçalhos

Esta seção lista vários nomes de cabeçalho que eram permitidos no Nginx 1.20.1, mas agora não são mais permitidos no Nginx 1.26.

Cenário Exemplos de nomes de cabeçalho
Caractere de controle no início, no fim ou entre o nome do cabeçalho { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Espaços em branco à esquerda e à direita no nome do cabeçalho {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
HTAB inicial e final no nome do cabeçalho {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Combinação inicial e final de HTAB, WS no nome do cabeçalho {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
NewLine (\n) entre o nome do cabeçalho seguido imediatamente por WS ou uma série de WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) entre o nome do cabeçalho seguido imediatamente por HTAB ou uma série de HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Retorno de carro (\r) NewLine (\n) entre o nome do cabeçalho seguido imediatamente por HTAB ou uma série de HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Retorno de carro (\r) Nova linha (\n) entre o nome do cabeçalho seguido imediatamente por WS ou uma série de WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Mudanças nos valores de cabeçalho

Esta seção mostra vários valores de cabeçalho que eram permitidos no Nginx 1.20.1, mas não no Nginx 1.26.

Cenário Exemplos
\r\n ou combinação de \r\n com WS ou HTAB permitida 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 combinação de \n com WS ou HTAB permitida 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"}

Mudança na resposta de falha HTTP

Esta seção aborda cabeçalhos que eram permitidos pelo Nginx antigo, mas foram rejeitados pelo processador de mensagens upstream, resultando em um código de status 400. No entanto, no Nginx 1.26, esses cabeçalhos causam falhas diretamente no Nginx, impedindo que a solicitação seja encaminhada ao processador de mensagens.

Para clientes que enviam esses cabeçalhos, o código de status HTTP permanece 400. No entanto, o corpo da resposta HTTP pode mudar, já que a falha agora será gerada pelo Nginx em vez do processador de mensagens.

Cenário Exemplos
HTAB ou WS entre HEADERNAME

O processador de mensagens rejeita essas solicitações. Com o Nginx 1.26, essas solicitações serão rejeitadas pelo próprio Nginx. O consumidor da API vai receber uma resposta de erro 400 com uma mensagem de erro do Nginx no corpo.

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