Java Migliori Prassi per Prevenire i Cross Site Scripting

Sono andato attraverso l’OWASP top ten di vulnerabilità, e trovano che la Cross-Site Scripting (xss) è quella che abbiamo per prendere appunti. C’era qualche modo le soluzioni consigliate. Uno ha dichiarato che non utilizzano la “lista nera” di convalida per rilevare XSS in input o di output di codifica. Ricerca e sostituzione di pochi caratteri (< e > e altri caratteri simili o frasi come script), è debole ed è stato attaccato con successo. Anche un incontrollato “<b>” tag è pericoloso, in alcuni contesti. XSS dispone di un sorprendente numero di varianti che lo rendono facile da ignorare blacklist di convalida. Un’altra soluzione, ha detto che uscita di codifica. Assicurarsi che tutti i dati forniti dall’utente, opportunamente codificato come entità (HTML o XML a seconda dell’uscita meccanismo) prima di eseguire il rendering. Quindi, quale è il modo migliore per evitare cross site scripting per convalidare e sostituire l’ingresso o la codifica di output ?

InformationsquelleAutor | 2009-07-21



3 Replies
  1. 41

    La prassi normale è di HTML-fuga qualsiasi controllata dall’utente, dati durante la visualizzazione delle in JSP, non durante elaborazione dati presentati in servlet, né durante la memorizzazione in DB. In JSP, è possibile utilizzare il JSTL (per installarlo, è sufficiente rilasciare jstl-1.2.jar in /WEB-INF/lib) <c:out> tag o fn:escapeXml funzione per questo. E. g.

    <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
    ...
    <p>Welcome <c:out value="${user.name}" /></p>

    e

    <%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
    ...
    <input name="username" value="${fn:escapeXml(param.username)}">

    Che sia. Nessun bisogno di una “lista nera”. Nota che la controllata dall’utente, i dati copre tutto che deriva da una richiesta HTTP: parametri della richiesta, il corpo e le intestazioni(!!).

    Se è HTML-fuga durante l’elaborazione dati inviati e/o la memorizzazione nel DB, poi tutto si sviluppa su codice commerciale e/o nel database. Che solo di manutenzione difficoltà e si rischia di fare doppio sfugge o più quando lo si fa in luoghi diversi (ad esempio, & sarebbe diventato &amp;amp; invece di &amp; in modo che l’utente finale si sarebbe letteralmente vedere &amp; invece di & in vista. Il codice di affari e DB sono di volta in volta non sensibili per XSS. Solo la vista. Si deve poi sfuggire solo destra c’ in vista.

    Vedere anche:

    • +1 ! Se solo potessimo in qualche modo configurare l’espressione EL default html fuga, quindi ci sarebbe bisogno di avere un sacco di c:out ovunque 🙂
    • Ah, voi avete risposto su questo problema qui : stackoverflow.com/questions/5887037/…
    • se non sbaglio, si sta già utilizzando JSF/Facelets, giusto? Tutti XSS la fuga è già fatto per voi, allora, sì.
    • Wow, ti ricordi ancora ! Sì, sono stato con Facelets, ma, attualmente, su un progetto che utilizza SpringMVC, e con JSP come la vista. Quindi il mio attuale conclusione è c:out durante la visualizzazione di input dell’utente, e EL per le pause.
    • Che cosa succede se c’è qualcosa nel valore di uscita come, <font color=”#FF0000″> sarebbe visualizzare, in quanto priva di prendere effetto.
    • utilizzare Jsoup#clean() per rimuovere potenzialmente dannosi HTML da una stringa. Vedi anche stackoverflow.com/questions/7722159/…
    • Ottima fonte, grazie!!
    • Ma ho anche un tag di ancoraggio con un po ‘ di JavaScript nel valore di attributo, quindi cosa potrei fare in questo caso?
    • Che cosa succede se si dispone di un JSONP API. Non si sa come sono i tuoi clienti intenzione di usarlo. Non sarebbe meglio eliminare le vulnerabilità quando la memorizzazione dei dati in questo caso?

  2. 6

    Utilizzare entrambi. Infatti consultare una guida come la OWASP XSS Prevenzione cheat sheet, sui possibili casi di utilizzo di uscita la codifica e la convalida dell’input.

    Di convalida dell’Input aiuta quando si può contare su di uscita di codifica, in alcuni casi. Per esempio, è meglio la convalida di ingressi che appare nell’Url, piuttosto che codifica Url stessi (Apache, non servirà un URL url-encoded). O per quella materia, la validazione dell’input che appaiono in JavaScript espressioni.

    In definitiva, una semplice regola empirica può aiutare – se non ti fidi di input dell’utente abbastanza o se si sospetta che alcune fonti possono causare attacchi di tipo XSS, nonostante l’uscita di codifica, convalidarlo in una whitelist.

    Dare un’occhiata al OWASP ESAPI codice sorgente su come l’uscita encoder input e i validatori sono scritti in una libreria di protezione.

  3. 0

    La mia preferenza è per codificare tutti i non-alphaumeric personaggi come HTML entità di caratteri numerici. Dal momento che quasi, se non tutti gli attacchi richiedono non alphuneric caratteri (come <“, ecc) questo dovrebbe eliminare un grande pezzo di uscita pericolose.

    Formato &#N, dove N è il valore numerico del carattere (basta lanciare il carattere di un int e concatenare una stringa per ottenere un valore decimale). Per esempio:

    //java-ish pseudocodice 
    StringBuffer safestrbuf = new StringBuffer(stringa.lunghezza()*4); 
    foreach(char c : string.split() ){ 
    if( Carattere.isAlphaNumeric(c) ) safestrbuf.append(c); 
    altro safestrbuf.append(""+(int)simbolo); 
    

    Avrete anche bisogno di essere sicuri che si stanno codifica immediatamente prima di output per il browser, per evitare la doppia codifica, o la codifica HTML, ma l’invio di una posizione diversa.

    • Lo spazio non alfanumerici, giusto?
    • Corretto. Lo spazio non è alfanumerico, e, dato questo molto draconiane algoritmo di codifica per &#32; . Questo può sembrare, non è necessario, ma pensare ad un caso in cui solo pericolosi noti personaggi del singolo, & le doppie virgolette sono trattati, se l’output è costituito dal seguente JSP frammento: <input name=pippo value=<%= userdata %> > se l’utente dovesse presentare un valore, ad esempio x onfocus=alert(1) s/egli sarebbe in grado di eseguire XSS. P. S. c’è un modo per formattare i commenti? Sto cercando una bella stampa, ma non è possibile…

Lascia un commento