Modifiche relative a Nginx 1.26 in Apigee Edge 4.53.00

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, è stata rafforzata l'adesione a RFC 7230, 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 contrabbando di richieste 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 degli algoritmi di crittografia supportati per le richieste in uscita potrebbe cambiare con questa release. Puoi controllare le crittografie supportate da OpenSSL sull'host del router per ottenere l'elenco aggiornato delle crittografie 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 erano 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

Spazi vuoti nelle intestazioni

Esistono tre modifiche principali:

  1. Alcuni nomi di intestazione consentiti in precedenza non sono più consentiti da Nginx 1.26. Le richieste con queste intestazioni causeranno un errore 400 Bad Request.
  2. Alcuni valori di intestazione consentiti in precedenza non sono più consentiti da Nginx 1.26. Le richieste con queste intestazioni causeranno anche un errore 400 Bad Request.
  3. Alcune intestazioni che in precedenza erano accettate da Nginx, ma causavano errori a valle nell'elaboratore dei messaggi, ora vengono rifiutate direttamente da Nginx. Sebbene queste intestazioni portino ancora a 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. Per le intestazioni, è consigliabile attenersi alle linee guida di RFC 7230.

Modifiche ai nomi delle intestazioni

Questa sezione elenca vari nomi di intestazioni consentiti in Nginx 1.20.1, ma non più 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 iniziale e finale 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"}
A capo (\n) tra il nome dell'intestazione seguito immediatamente da uno spazio o da una serie di spazi {"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 uno spazio vuoto o da una serie di spazi vuoti {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Modifiche ai valori dell'intestazione

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

Scenario Esempi
\r\n o una combinazione di \r\n con WS o HTAB consentita 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 una combinazione di \n con WS o HTAB consentita tra HEADERVALUE {"Header61", "Valore\n 61Più righe"},
{"Header62", "Valore\n 63Più righe"},
{"Header65", "Valore\n\t65"},
{"Header66", "Valore\n\t\t66"},
{"Header67", "Valore\n 67"},
{"Header68", "Valore\n 68"}

Modifica della risposta di errore HTTP

Questa sezione illustra le intestazioni consentite dal vecchio Nginx, ma rifiutate dall'elaboratore di messaggi a monte, con un conseguente codice di stato 400. Tuttavia, in Nginx 1.26, queste intestazioni causano errori direttamente in Nginx, impedendo l'inoltro della richiesta all'elaboratore di messaggi.

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

Scenario Esempi
HTAB o WS tra HEADERNAME

Il Message Processor rifiuta queste richieste. Con Nginx 1.26, queste richieste verranno rifiutate da Nginx stesso. Il consumatore 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"}