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. Confira mais detalhes sobre essas mudanças 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á tenha sido reforçado 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 aceitos

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 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 anteriormente agora não são mais permitidos pelo Nginx 1.26. As solicitações com esses cabeçalhos resultarão em um erro 400 Bad Request.
  2. Alguns valores 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 também resultarão 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. Estes são somente exemplos, e esta não é 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"}
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) ou quebra de 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 do cabeçalho

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

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