errore di sicurezza - rapporto veracode - iniezione crlf

Question

Ho ricevuto il rapporto veracode per la mia app javaEE. Aveva un difetto in ogni registrazione (usando log4j), quindi aggiungo il StringEscapeUtils.escapeJava(log) a tutti, ma veracode continua a segnalarli come difetti di sicurezza.

Questa è una soluzione giusta? Cos'altro posso fare?

Si tratta di informazioni rapporto: Titolo: improprio neutralizzazione Uscita per Logs

Descrizione: Una chiamata di funzione potrebbe causare un attacco di forgiare registro. La scrittura di dati non pubblicizzati dall'utente non salvati in un file di registro consente a un utente malintenzionato di creare voci di registro o di immettere contenuti dannosi in file di registro. I file di registro danneggiati possono essere utilizzati per coprire le tracce di un attaccante o come meccanismo di consegna per un attacco a un'utilità di visualizzazione o di elaborazione dei registri. Ad esempio, se un amministratore web utilizza un'utilità basata su browser per esaminare i registri, potrebbe essere possibile un attacco di scripting cross-site.

Raccomandazioni: Evitare di incorporare direttamente l'input dell'utente nei file di registro quando possibile. Disinfetta i dati forniti dall'utente per costruire voci di registro utilizzando un meccanismo di registrazione sicuro come OWASP ESAPI Logger, che rimuoverà automaticamente ritorni a capo e feed di riga inaspettati e può essere configurato per utilizzare la codifica di entità HTML per dati non alfanumerici . Solo scrivere codice di blacklist personalizzato quando assolutamente necessario. Convalidare sempre l'input fornito dall'utente per garantire che sia conforme al formato previsto, utilizzando le routine di convalida dei dati centralizzate quando possibile.

Si consiglia di utilizzare ESAPI, ma è un progetto molto grande quindi ho bisogno la soluzione più semplice, tht per questo che ho provato con String.escape 'StringEscapeUtils.escapeJava (log)'

Thx in anticipo!

Answer 1

Sono a capo del gruppo Veracode Application Security Consulting e posso rispondere alla tua domanda in dettaglio. Il luogo migliore per la conversazione è Support@veracode.com, poiché la discussione potrebbe coinvolgere dettagli specifici sui risultati che probabilmente vorremmo evitare di rendere pubblici.

La risposta breve è StringEscapeUtils.escapeJava() è efficace nell'eliminare il tipico rischio CRLF, ma non è uno dei meccanismi che il nostro sistema riconosce automaticamente in quanto vi sono situazioni in cui potrebbe essere insufficiente.

Il sistema Veracode dispone di un meccanismo per contrassegnare questi risultati in modo appropriato in modo che non causino confusione.

Si prega di contattare Veracode Support (support@veracode.com), e saremo in grado di parlare in dettaglio.

Cordiali saluti, Jim.

Answer 2

In questo rapporto sono confluiti due problemi.

In primo luogo, vi è un'iniezione di log - utilizzando un carattere di nuova riga per riversarsi in una riga di registro separata. StringEscapeUtils.escapeJava produce output con delimitatori di riga e caratteri non ASCII sfuggiti, il che, in linea di principio, assicura che il problema sia risolto. Veracode non lo sa, però - come uno scanner automatico non sa abbastanza su cosa stia facendo quel metodo per essere sicuro di poterlo dire, quindi deve segnalare che potrebbe esserci ancora una vulnerabilità lì. Naturalmente, Veracode non può sapere su ogni funzione di escape nel codice di libreria di terze parti.

L'iniezione di registro può verificarsi anche quando si utilizzano separatori all'interno di una linea di registro, ad esempio Bad thing happened with parameters {0} and {1}. In questo caso, se un utente malintenzionato avesse la stringa " and " in uno dei parametri, non sarebbe possibile ricreare esattamente quali dati erano in quale parametro. La risposta è quella di circondare i parametri con delimitatori che non compaiono nell'output della funzione di escape, ad esempio inserire virgolette doppie attorno a ciascun valore e utilizzare escapeJava per evitare qualsiasi carattere di virgoletta doppia nel valore.

Il secondo attacco si verifica all'esterno dell'applicazione, quando viene utilizzato uno strumento per visualizzare i registri. Se questo strumento presenta una vulnerabilità di iniezione, i metacaratteri nei dati del registro possono diventare attivi. L'esempio classico è la visualizzazione dei registri in un'interfaccia Web che li copia direttamente nella pagina senza eseguire l'escape, con conseguente immissione di codice HTML e conseguentemente di script tra siti nell'applicazione di visualizzazione dei registri.

Se si può essere sicuri che si stiano visualizzando solo i registri in strumenti che non presentano bug stupidi come questo, non è necessario preoccuparsene.

Altrimenti, prova a sfuggire a tutti i metacaratteri dalle lingue che ritieni possano essere interessate. Tipicamente < e & per HTML. Se non si desidera eseguire l'escape HTML di tutti i dati di registro non HTML, un altro modo in cui è possibile farlo sarebbe sostituire quei caratteri con equivalenti di escape come \u003E nell'output di escapeJava.

Ancora una volta, Veracode non sarà in grado di funzionare automaticamente che ciò che stai facendo è necessariamente sicuro, quindi dovrai contrassegnare tali rapporti come ignorati/trattati una volta che sei soddisfatto.

Answer 3

Utilizzare StringEscapeUtils.escapeHtml (log) per evitare le iniezioni HTML e potrebbe risolvere il problema.

Answer 4

Ho incontrato lo stesso problema e generalmente ignoro questo difetto per un semplice motivo: un logger mi fornisce solo un evento di registro. Non dovrebbe interessare la formattazione (l'esposizione dei dati sensibili è un altro problema).

La soluzione qui è di aggiungere un adeguato filtro/post-elaborazione nell'appliance che scrive l'evento di registro nel file di registro. A questo punto, è possibile rimuovere i caratteri speciali (\0, \r - ritorno a capo, \b - backspace, \x1b - fuga e \x7f - cancellare) e sostituirlo con \n\n... per l'impossibilità di iniettare le linee di log falsi nel registro.

Quando si esegue questa operazione, è possibile ignorare in modo sicuro tutti questi difetti.

Inoltre, se un amministratore di sistema utilizza gli strumenti errati per esaminare i file di registro (qualsiasi cosa che esegua sequenze di escape, \r e backspace), deve essere attivato.