Mudanças no Nginx 1.30 na Apigee Edge 4.54.00

Visão geral das mudanças do Nginx

O Apigee Edge para nuvem privada 4.54.00 inclui uma atualização obrigatória para a versão 1.30 do Nginx nos roteadores do Edge.

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:

Como lidar com 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.

Como lidar com 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á fosse fortificado 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 aceitas

A lista de criptografias aceitas para solicitações de saída pode mudar com essa versão. Confira as criptografias aceitas pelo OpenSSL no host do roteador para receber a lista atualizada de criptografias disponíveis.

Tamanhos de chave aceitos

Anteriormente, 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 de saída.

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 são proibidos 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 anteriormente 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 anteriormente pelo Nginx, mas causavam falhas downstream no processador de mensagens, agora são rejeitados diretamente pelo Nginx. Embora esses cabeçalhos ainda levem a falhas de API, as mensagens de falha HTTP vão mudar.

A seção abaixo fornece exemplos de vários nomes e valores de cabeçalho que não são permitidos. Estes são apenas exemplos e podem não ser uma lista exaustiva. 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 são proibidos 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ço em branco inicial e final 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"}
Nova linha (\n) entre o nome do cabeçalho, seguida imediatamente por WS ou uma série de WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Nova linha (\n) entre o nome do cabeçalho, seguida imediatamente por HTAB ou uma série de HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Retorno de carro (\r) Nova linha (\n) entre o nome do cabeçalho, seguida 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, seguida imediatamente por WS ou uma série de WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Mudanças nos valores dos cabeçalhos

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 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 permitido 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 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 ao processador de mensagens.

Para clientes que enviam esses cabeçalhos, o código de status HTTP vai permanecer 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"}