Alterações do Nginx 1.26 no Apigee Edge 4.53.00

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 melhorar 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 processamento de espaços em branco em 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 contrabando de solicitações envolve o envio de solicitações HTTP com cabeçalhos Content-Length e Transfer-Encoding. Embora o Apigee Edge já estivesse protegido contra esses ataques, o Nginx agora bloqueia explicitamente as solicitações que contêm os dois cabeçalhos. Se uma solicitação for enviada, o Nginx vai responder com um erro 400 Bad Request.

Criptografias compatíveis

A lista de cifras com suporte para solicitações do sentido norte pode mudar com essa versão. É possível verificar as criptografias compatíveis com o OpenSSL no host do roteador para conferir a lista atualizada das 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 para solicitações do lado do servidor.

Apêndice

Espaços em branco nos cabeçalhos

Há três mudanças principais:

  1. Alguns nomes de cabeçalho que eram permitidos anteriormente agora não são mais permitidos pelo Nginx 1.26. As solicitações com esses cabeçalhos vão resultar em um erro 400 Bad Request.
  2. Certos valores de cabeçalho que eram permitidos anteriormente não são permitidos 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 no processador de mensagens, agora são rejeitados diretamente pelo Nginx. Embora esses cabeçalhos ainda levem a 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. Esses são somente exemplos e podem não ser uma lista completa. É recomendável seguir as diretrizes do 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 iniciais e finais no nome do cabeçalho {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Liderança e HTAB à direita no nome do cabeçalho {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Liderança e Combinação à direita 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) NewLine (\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 diversos valores de cabeçalho que foram permitidos no Nginx 1.20.1, mas não permitidos no Nginx 1.26.

Cenário Exemplos
\r\n ou uma 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", "Valor\n\t65"},
{"Header66", "Valor\n\t\t66"},
{"Header67", "Valor\n 67"},
{"Header68", "Valor\n 68"}

Mudança na resposta de falha HTTP

Esta seção aborda os cabeçalhos que eram permitidos pelo Nginx antigo, mas 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 para o 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 sã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"}