L'uso di HttpServletRequest.getQueryString () per un'intestazione di risposta è vulnerabile alla suddivisione della risposta?

Question

L'uso di HttpServletRequest.getQueryString () per un'intestazione di risposta è vulnerabile alla suddivisione della risposta?

#1 da (1 voti)

7

Mi è stato detto che usando HttpServletRequest.getQueryString() in un'intestazione di risposta rende la mia applicazione suscettibile agli attacchi di divisione della risposta HTTP, ma non vedo come.

È chiaro nel caso di getParameter(String) , che decodifica i valori con codifica percentuale, ma getQueryString() non lo fa. Dalla documentazione:

The value is not decoded by the container.

Frammento di codice sorgente che illustra cosa sto facendo:

String path = "some_url";

String qs = req.getQueryString();
if (qs != null)
    path += "?" + qs;

// response instanceof HttpServletResponse
response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY);
response.setHeader("Location", path);

Ho provato a riprodurre il problema, e ho appena ricevuto le nuove righe codificate per percentuale da me riecheggiate nella risposta. Quando cambio il codice in getParameter(…) , funziona come previsto (eccetto il fatto che il mio contenitore è abbastanza carino da eliminare le righe nuove dal valore dell'intestazione, ma almeno in teoria funziona). Questa domanda simile su Stack Overflow chiede lo stesso, e un commento alla risposta indicando che getQueryString() non decodifica non ha ricevuto risposta.

Mi sto perdendo qualcosa qui? O è il consiglio che ho sbagliato?

java web-application response-splitting

posta mwl 29.11.2015 - 22:40

fonte

1 risposta

Leggi altre domande sui tag java web-application response-splitting

La verifica di una frazione aggiuntiva di un file riduce le possibilità di collisione? Come compilare java_atomicreferencearray (CVE-2012-0507) exploit per eseguire calc.exe sul sistema?

score 1 · Answer 1

Lo schema generale di utilizzo dei dati che proviene dall'utente senza sanitizzarlo è una fonte di vulnerabilità. Cose tipiche come XSS e SQLi. In questo caso stai prendendo l'input dall'utente e rendendolo direttamente un'intestazione. Ciò potrebbe comportare una suddivisione della risposta, un'iniezione di intestazione e forse un altro problema o due (ad esempio: CSRF potrebbe essere possibile se si può iniettare Javascript). Ma tu affermi che:

my container is nice enough to strip the newlines from the header value

quindi questo sta impedendo l'exploit reale.

Sospetto che anche se si dovesse filtrare l'input come:

path += "?" + sanitize(qs);

per una funzione sanitize appropriata (ad esempio dal progetto AntiSamy di OWASP ) che il tuo analizzatore statico continua a darti questo risultato. Quindi, alla fine, contrassegnerai questo risultato come un falso positivo ( Not an issue se stai usando Fortify). L'unica domanda è se devi includere una modifica del codice prima di contrassegnare il risultato come falso positivo.

La mia opinione è che se l'API afferma esplicitamente che è responsabile della gestione sicura di newline e altri caratteri speciali, non è necessaria alcuna azione da parte dell'utente. Quando guardo il Javadoc per HttpServletResponse.setHeader , non vedo alcuna menzione di come verranno gestiti i caratteri speciali. Quindi, a meno che la specifica non stabilisca esplicitamente una gestione sicura di ciò (non penso che lo faccia, ma non ho trovato questo nelle specifiche Servlet), raccomanderei di sanitizzare l'input e rieseguire lo scanner statico. Se, come mi aspetto, continua a segnalare questo problema, quindi contrassegnarlo come un falso positivo e stare tranquilli che tutto va bene.

La ragione per cui ritengo che dovresti fidarti di questo comportamento se è specificata nelle specifiche è che questo è l'unico comportamento garantito. Una nuova versione del contenitore Servlet o di un altro contenitore potrebbe modificare questo comportamento. È molto improbabile che rilevi un tale cambiamento anche se ciò potrebbe rendere vulnerabile il tuo sito.