Lunghezze di intestazione HTTP di grandi dimensioni / sovradimensionate e implicazioni di sicurezza

Diversi firewall (o IDS, IPS, UTM, NGFW, indipendentemente dal loro nome) hanno limiti sulla lunghezza del contenuto che analizzano per malware (in genere circa 10 MB, ma a volte anche inferiore). Alcuni includono la lunghezza dell'intestazione HTTP in questo calcolo. In questo caso l'analisi del corpo HTTP (contenente il malware) può essere aggirata quando l'intestazione HTTP è già più grande del limite di ispezione.

L'RFC HTTP non corregge la lunghezza dell'intestazione, ma sta almeno affermando:

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

Questo era per la prima riga. Per le intestazioni che hai (in grassetto aggiunto):

HTTP does not place a predefined limit on the length of each header field or on the length of the header section as a whole, as described in Section 2.5. Various ad hoc limitations on individual header field length are found in practice, often depending on the specific field semantics.

A server that receives a request header field, or set of fields, larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (Section 9.5).

A client MAY discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such that the dropped value(s) can be safely ignored without changing the message framing or response semantics.

E in pratica il limite di 8000 byte si trova di solito anche nelle intestazioni.

Quando gestisci intestazioni lunghe, avere una sola intestazione ignorata è pericolosa ( Content-Length:<10,000spaces>42 ). La rimozione di un'intestazione può trasformare completamente il significato del flusso HTTP (non solo il messaggio corrente, ma anche altri messaggi pipeline).

Ma la rimozione dell'intestazione non è l'unico rischio, in passato era un vecchio troncamento a 5000 byte di IIS. Potrebbe anche essere usato per nascondere un payload HTTP attivo (come un'intestazione Transfer-Encoding: chunked<5000 spaces>, gzip o Content-Length: <4883 spaces>42 dove qualsiasi attore che rimuove la fine dell'intestazione potrebbe interpretare male la lunghezza reale del messaggio (e magari trovare un nuovo messaggio pipeline che altri attori HTTP non ha visto).

Nel tuo server di ritorno non tanto, potresti avere qualche software che tronca o non funziona correttamente, ma ci sono alcuni vettori di attacco che usano l'invio di intestazioni HTTP malformate / negative / craftate. contrabbando / scissione / avvelenamento .. tu dai il nome. Dovresti essere preoccupato di riceverli.