Modifiche di Nginx 1.30 in Apigee Edge 4.54.00

Panoramica delle modifiche di Nginx

Apigee Edge for Private Cloud 4.54.00 include un upgrade obbligatorio a Nginx versione 1.30 sui router Edge.

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 la conformità alla 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 request smuggling prevede l'invio di richieste HTTP con le intestazioni Content-Length e Transfer-Encoding. Sebbene Apigee Edge fosse 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.

Cifratura supportata

L'elenco delle cifrature supportate per le richieste in direzione nord 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 direzione nord.

Appendice

Spazi vuoti nelle intestazioni

Esistono 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. Anche le richieste con queste intestazioni genereranno un 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 causino ancora errori API, i messaggi di errore HTTP cambieranno.

La sezione seguente fornisce esempi di vari nomi e valori di intestazione non consentiti. Questi sono solo esempi e potrebbero non essere un elenco esaustivo. Ti consigliamo di rispettare le linee guida della RFC 7230 per le intestazioni.

Modifiche ai nomi delle intestazioni

In questa sezione sono elencati vari nomi di intestazione 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"}
Nuova riga (\n) tra il nome dell'intestazione, seguita immediatamente da WS o da una serie di WS {"Header\n 57Mutiline", "Value57"}
{"Header\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, seguita 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, seguita immediatamente da WS o da una serie di WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Modifiche ai valori delle intestazioni

In questa sezione vengono mostrati vari valori di intestazione consentiti in Nginx 1.20.1, ma non più consentiti 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 perché l'errore verrà 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 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"}