Panoramica delle modifiche di Nginx 1.26
Con il rilascio di Nginx 1.26, sono state introdotte diverse importanti modifiche per migliorare la sicurezza e garantire la conformità agli standard HTTP. Di seguito sono riportati i principali aggiornamenti:
Gestione degli spazi vuoti nei nomi e nei valori delle intestazioni
Per migliorare la sicurezza, l'aderenza alla specifica RFC 7230 è stata rafforzata, in particolare per quanto riguarda la gestione degli spazi bianchi 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
. Sebbene Apigee Edge sia già stato fortificato contro questi attacchi, Nginx ora 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.
Crittografia supportate
L'elenco degli algoritmi di crittografia supportati per le richieste in uscita potrebbe cambiare con questa release. Puoi controllare le crittografie supportate da OpenSSL sul tuo host router per ottenere l'elenco aggiornato delle crittografie disponibili.
Dimensioni dei tasti 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:
- 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.
- Alcuni valori di intestazione precedentemente consentiti non sono ora consentiti da Nginx 1.26. Le richieste con queste intestazioni comporteranno anche un errore 400 Richiesta non valida.
- Alcune intestazioni che in precedenza erano accettate da Nginx, ma causavano errori a valle nel processore di messaggi, ora vengono rifiutate direttamente da Nginx. Anche se queste intestazioni portano comunque 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 intestazioni |
---|---|
Carattere di controllo all'inizio, alla fine o all'interno del nome dell'intestazione | { '\u0001'Intestazione0, Valore0 } { Intestazione6'\u0002', Valore6 } { Intestazione'\u0005'4, Valore4 } |
All'avanguardia e spazio vuoto finale nel nome dell'intestazione | {"Header2 ", "Value2"} {" Header3", "Value3"} {" Header4 ", "Value4"} |
All'avanguardia e HTAB finale nel nome dell'intestazione | {"\tHeader11", "Value11"} {"Header12\t", "Value12"} {"\tHeader13\t", "Value13"} |
All'avanguardia e combinazione 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 spazi o da una serie di spazi | {"Intestazione\n 57Mutiline", "Value57"} {"Intestazione\n 58Mutiline", "Value58"} |
Nuova riga (\n) tra il nome dell'intestazione seguita 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 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 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", "Value\n 61Multiline"}, {"Header62", "Value\n 63Multiline"}, {"Header65", "Valore\n\t65"}, {"Header66", "Valore\n\t\t66"}, {"Header67", "Valore\n 67"}, {"Header68", "Valore\n 68"} |
Modifica nella risposta all'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 tali 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 processore di messaggi rifiuta tali richieste. Con Nginx 1.26, queste richieste verranno rifiutate da Nginx stessa. Il consumatore dell'API riceverà una risposta di errore 400 con un messaggio di errore Nginx nel corpo. |
{"Intestazione 5", "Value5"}, {"Intestazione\t14", "Value14"}, {"Intestazione\t 32", "Value32"}, {"Intestazione \t33", "Value33"}, {"Intestazione- 36", "Value36"}, {"Intestazione-\t40", "Value40"}, {"Intestazione 4a", "Value4a"}, {"Intestazione\t 59", "Value59"}, {"Header\t 60", "Value60"} |