Modifiche di Nginx 1.26 in Apigee Edge 4.53.01

Panoramica delle modifiche di Nginx 1.26

Con il rilascio di Nginx 1.26, sono state introdotte diverse modifiche importanti per migliorare la sicurezza e garantire la conformità agli standard HTTP. Di seguito sono riportati gli aggiornamenti principali:

Gestione degli spazi vuoti nei nomi e nei valori delle intestazioni

Per migliorare la sicurezza, l'adesione alla RFC 7230 è stata rafforzata, in particolare per quanto riguarda la gestione degli spazi vuoti nelle intestazioni. Ulteriori dettagli su queste modifiche sono disponibili nell'appendice.

Gestione delle intestazioni Content-Length e Transfer-Encoding

Una delle tecniche comuni utilizzate negli attacchi di request smuggling prevede l'invio di richieste HTTP con intestazioni Content-Length e Transfer-Encoding. Anche se Apigee Edge era già protetto da questi attacchi, ora Nginx blocca esplicitamente le richieste che contengono entrambe le intestazioni. Se viene inviata una richiesta di questo tipo, Nginx risponderà con un errore 400 Bad Request.

Tipi di crittografia supportati

L'elenco delle cifrature supportate per le richieste in uscita potrebbe cambiare con questa release. Puoi controllare le cifrature supportate da OpenSSL sull'host del router per ottenere l'elenco aggiornato delle cifrature disponibili.

Dimensioni delle chiavi supportate

In precedenza, le chiavi RSA, DSA e DH di dimensioni inferiori a 2048 bit e le chiavi ECC di dimensioni inferiori a 224 bit venivano accettate per impostazione predefinita. Tuttavia, con questo aggiornamento, queste chiavi non saranno più consentite per le connessioni TLS unidirezionali e bidirezionali per le richieste in uscita.

Appendice

Spazio vuoto nelle intestazioni

Sono state apportate tre modifiche principali:

  1. Alcuni nomi di intestazione precedentemente consentiti ora non sono più consentiti da Nginx 1.26. Le richieste con queste intestazioni genereranno un errore 400 Bad Request.
  2. Alcuni valori di intestazione precedentemente consentiti ora non sono più consentiti da Nginx 1.26. Le richieste con queste intestazioni restituiranno anche l'errore 400 Bad Request.
  3. Alcune intestazioni precedentemente accettate da Nginx ma che causavano errori a valle nel processore di messaggi ora vengono rifiutate direttamente da Nginx. Sebbene queste intestazioni continuino a causare errori dell'API, i messaggi di errore HTTP cambieranno.

La sezione seguente fornisce esempi di vari nomi e valori di intestazione non consentiti. Si tratta unicamente di esempi e l'elenco potrebbe non essere esaustivo. È consigliabile rispettare le linee guida della RFC 7230 per le intestazioni.

Modifiche ai nomi delle intestazioni

Questa sezione elenca vari nomi di intestazione consentiti in Nginx 1.20.1, ma ora non consentiti in Nginx 1.26.

Scenario Esempi di nomi di intestazione
Carattere di controllo all'inizio, alla fine o tra il nome dell'intestazione { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Spazi vuoti iniziali e finali nel nome dell'intestazione {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
HTAB iniziali e finali nel nome dell'intestazione {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Combinazione iniziale e finale di HTAB, WS nel nome dell'intestazione {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
NewLine (\n) tra il nome dell'intestazione seguito immediatamente da WS o da una serie di WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) tra il nome dell'intestazione seguito immediatamente da HTAB o da una serie di HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Ritorno a capo (\r) Nuova riga (\n) tra il nome dell'intestazione seguito immediatamente da HTAB o da una serie di HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Ritorno a capo (\r) Nuova riga (\n) tra il nome dell'intestazione seguito immediatamente da WS o da una serie di WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Modifiche ai valori delle intestazioni

Questa sezione mostra vari valori di intestazione consentiti in Nginx 1.20.1, ma non in Nginx 1.26.

Scenario Esempi
\r\n o combinazione di \r\n con WS o HTAB consentiti tra 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 combinazione di \n con WS o HTAB consentiti tra 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"}

Modifica della risposta di errore HTTP

Questa sezione riguarda le intestazioni consentite dal vecchio Nginx, ma rifiutate dal processore di messaggi upstream, con conseguente codice di stato 400. Tuttavia, in Nginx 1.26, queste intestazioni causano errori direttamente in Nginx, impedendo l'inoltro della richiesta al processore di messaggi.

Per i client che inviano queste intestazioni, il codice di stato HTTP rimarrà 400. Tuttavia, il corpo della risposta HTTP potrebbe cambiare, in quanto l'errore verrà ora generato da Nginx anziché dal processore di messaggi.

Scenario Esempi
HTAB o WS tra HEADERNAME

Il processore di messaggi rifiuta queste richieste. Con Nginx 1.26, queste richieste verranno rifiutate da Nginx stesso. Il consumer dell'API riceverà una risposta di errore 400 con un messaggio di errore Nginx nel 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"}