Revisione del codice su un'iniezione di intestazione In Java: qualche aiuto?

Question

Revisione del codice su un'iniezione di intestazione In Java: qualche aiuto?

#1 da (9 voti)

6

Sto verificando un pezzo di codice Java che potrebbe essere vulnerabile a Iniezione header :

String headerValue =request.getParameter("headerVal");

//escaping CRLF
headerValue = headerValue.replace("\n", "");
headerValue = headerValue.replace("\r", "");
response.addHeader("myheader",redirection);

Questo codice è presente direttamente nella vista di livello (jsp).

Per quanto ne so, questo pezzo di codice non tiene conto del fatto che CRLF potrebbe essere iniettato in codifica diversa secondo le mie letture.

In altre parole, vorrei segnalare al team DEV come un problema di canonizzazione.

Perché penso che gli sviluppatori lo negheranno, sto provando a impostare una dimostrazione di concetto con un progetto HelloWorld con Tomcat6 ma sembra che Tomcat stia impedendo di farlo in background.

Hai altri argomenti oltre a Canonicalization per giustificare questo difetto? O sono strongmente in errore e questo codice è sicuro? Grazie in anticipo.

Frenchy

injection code-review

posta Omar Elfada 28.12.2011 - 17:15

fonte

1 risposta

Leggi altre domande sui tag injection code-review

PCI DSS è applicabile ad altre soluzioni rispetto a quelle che si occupano di carte di pagamento? Come convalidare correttamente i reindirizzamenti HTTP?

score 9 · Answer 1

In linea di principio le intestazioni HTTP sono ISO-8859-1 secondo RFC 2616. In pratica il contenuto non ASCII nelle intestazioni HTTP sarà in una codifica diversa a seconda del browser (e anche per IE locale), ma sempre un superset ASCII . Di conseguenza, CR e LF sarebbero invariabilmente codificati come 0x0D e 0x0A, quindi non dovrebbe essere qualcosa di cui preoccuparsi se li stai sostituendo.

L'unico punto in cui la codifica entrerebbe in gioco sarebbe per le sequenze eccessivamente lunghe di UTF-8. Ad esempio 0x0A potrebbe essere codificato come 0xC0 0x8A. Questo non è valido, ma è stato accettato da vari decoder UTF-8 in passato. Quindi, se:

stai utilizzando una codifica [predefinita] non UTF-8 nella tua app Web, in modo che questa sequenza di byte possa andare avanti senza che Java si sia lamentato che era un periodo troppo lungo e
lo user-agent a cui stavi inviando l'intestazione doveva decodificare le intestazioni in blocco utilizzando UTF-8 e
lo user-agent ha permesso di utilizzare sequenze UTF-8 eccessivamente lunghe

allora sì, potresti ottenere attacchi di contrabbando di intestazione riflettendo un parametro in un'intestazione di risposta.

Con gli user-agent di oggi questa è una proposizione piuttosto improbabile, ma in generale direi che vale la pena di rimuovere tutti i caratteri non ASCII dai valori di intestazione, solo perché sono gestiti in modo incoerente attraverso i browser in modo da essere inutili in ogni caso . Ti consiglio anche di filtrare tutti i caratteri di controllo 0x00-0x1F, non solo quelli di nuova riga.