XSS prevenzione in JSP/Servlet applicazione web

Come posso prevenire attacchi di tipo XSS in una JSP/Servlet applicazione web?

InformationsquelleAutor newbie | 2010-04-17



8 Replies
  1. 93

    XSS possono essere evitati in JSP utilizzando JSTL <c:out> tag o fn:escapeXml() EL funzione quando (ri)visualizzazione controllata dall’utente, ingresso. Questo include i parametri della richiesta, le intestazioni, i cookie, URL, corpo, etc. Nulla di cui hai estratto l’oggetto della richiesta. Anche l’utente di input controllato dal precedente richieste che sono memorizzati in un database deve essere sfuggito durante la visualizzazione delle.

    Per esempio:

    <p><c:out value="${bean.userControlledValue}"></p>
    <p><input name="foo" value="${fn:escapeXml(param.foo)}"></p>

    Questo escape dei caratteri che possono malform il rendering HTML come <, >, ", ' e & in HTML/XML entità come &lt;, &gt;, &quot;, &apos; e &amp;.

    Nota che non hai bisogno di sfuggire in Java (Servlet) del codice, dal momento che essi sono innocui là. Alcuni possono optare, per poi fuggire durante richiesta di elaborazione (come in Servlet o Filtro) invece di risposta di elaborazione (come in JSP), ma in questo modo si rischia che i dati inutilmente di ottenere il doppio di escape (es. & diventa &amp;amp; invece di &amp; e, infine, l’utente dovrebbe vedere &amp; essere presentato), o che il DB-i dati memorizzati diventa unportable (ad esempio, quando esportazione dei dati in formato JSON, CSV, XLS, PDF, ecc che non richiede HTML fuoriuscita di tutti). Puoi anche perdere il controllo sociale, perché non si sa più ciò che l’utente ha effettivamente compilati. Sarebbe come essere un amministratore del sito piaciuto sapere quali utenti/IPs sta tentando di eseguire XSS, in modo che si può facilmente tenere traccia di loro e intervenire di conseguenza. La fuga durante l’elaborazione della richiesta deve solo essere utilizzato solo come ultima risorsa quando si ha realmente bisogno per risolvere un treno relitto di mal sviluppato legacy applicazione web nel più breve tempo possibile. Ancora, si dovrebbe in ultima analisi, riscrivere il file JSP per diventare XSS-cassetta di sicurezza.

    Se desideri visualizzare nuovamente sotto il controllo dell’utente di input come HTML in cui si desidera consentire solo un sottoinsieme di tag HTML come <b>, <i>, <u>, ecc, allora avete bisogno di disinfettare l’ingresso da parte di una whitelist. È possibile utilizzare un parser HTML come Jsoup per questo. Ma, molto migliore è quello di introdurre un semplice linguaggio di markup come Markdown (anche qui su Stack Overflow). È quindi possibile utilizzare un Markdown parser come CommonMark per questo. Ha anche incorporato HTML sanificazione capacità. Vedere anche Sto cercando un Java HTML encoder.

    L’unica preoccupazione in lato server per quanto riguarda il database è SQL injection prevenzione. È necessario assicurarsi che non avete mai stringa-concatenare utente controllato da ingresso direttamente in SQL o JPQL query e che si sta utilizzando le query con parametri in tutto il modo. In JDBC termini, questo significa che si dovrebbe usare PreparedStatement invece di Statement. In JPA termini, utilizzare Query.


    Un’alternativa sarebbe la migrazione da JSP/Servlet Java EE framework MVC JSF. Esso ha incorporato XSS (e CSRF!) prevenzione su tutto il luogo. Vedere anche CSRF, XSS e SQL Injection attacco di prevenzione in JSF.

    • Solo perché stai usando Hibernate, non significa che è sicuro da SQL injection. Vedere blog.harpoontech.com/2008/10/… per esempio.
    • che non è vero. È solo il caso quando hai stringa concatenando utente controllato da ingresso direttamente in SQL/HQL/JPQL query come "SELECT ... WHERE SOMEVAL = " + someval invece di utilizzare le query con parametri, come ti ho mostrato. Nessuno ORM in grado di proteggere contro questo tipo di sviluppatore errori.
    • Doh! Avevo invertito. Vulnerabili esempio: Query Query = session.createQuery(“SELECT * FROM TABELLA WHERE SOMEVAL =” + someval); Utilizzando la sintassi di associazione “:” in Sospensione (come il mio esempio di cui sopra) impedisce di SQL injection. Eliminazione commento per impedire a qualcuno di usare il mio cattivo esempio.
    • Penso che tu NON debba validare il server pure. Tutti la convalida può essere ignorato da alterare i parametri HTTP. E a volte, i dati che vi ostinate possono essere utilizzati da altre applicazioni in un enterprise app. A volte non hai accesso a il punto di vista delle altre applicazioni, quindi è necessario sanitze l’ingresso prima della memorizzazione nel database.
    • non sei la comprensione del problema.
    • si prega di espandere.
    • Ciao Bal, utilizzando il vostro suggerimento ho rimosso 4 XSS problemi nella mia app grazie mille per la soluzione utile. Qui ho bisogno di un vostro suggerimento di nuovo come mi visualizzazione dom oggetto utilizzando jstl massima espressione come <div><c:out value="${htmlContent}" escapeXml="false" /></div> qui htmlContentvalore è qualcosa di simile a <span><h1>Hi</h1></span> (questo valore provenienti da database) ora, se io rimuovere escapeXml="false" da c:out quindi le sue manifestazioni, come è a pagina quindi se mantenere escapeXml="false" sua analisi l’oggetto dom correttamente, ma quando il mio htmlContent avere il codice di script quindi xss problema è in arrivo.
    • se htmlContent è <span><h1><script>alert("Hi");</script></h1></span> quindi se io uso <c:out value="${htmlContent}" escapeXml="false" /></div> in jsp poi sul browser dell’utente otterrà finestra di avviso, quindi potrebbe leades XSS problema. Si prega di suggerire a me quello che posso fare in questa situazione.
    • Basta leggere il 4 ° paragrafo della risposta che dice qualcosa a proposito di trattare con la controllata dall’utente, HTML.
    • Grande risposta @BalusC Grazie mille! Domanda veloce, però se non ti dispiace. Quindi non dovrei fuggire html dell’input dell’utente, solo quando la visualizzazione? Che cosa si intende per doppia fuga? E se no, come si fa a sfuggire l’input dell’utente tramite una textarea, non un campo di input? È ( htmlEscape=”true” ) è corretta?
    • Si prega di notare: “HTML codifica di entità non funziona se si sta mettendo dati non attendibili all’interno di un <script> tag ovunque, o un gestore di eventi attributo come onmouseover, o all’interno di CSS, o in un URL.” github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/…
    • Yup, il caso di inserimento di dati non attendibili all’interno di codice JS, è necessario JS-codifica invece di HTML-codificare. E, in caso di inserimento di dati non attendibili all’interno di codice CSS, è necessario CSS-codificare invece di HTML-codificare. E, in caso di inserimento di dati non attendibili all’interno di Url, è necessario la codifica URL invece di HTML-codificare. La codifica HTML deve essere utilizzato solo per mettere dati non attendibili all’interno del codice HTML.

  2. 12

    Come-per-prevenire-xss è stato chiesto più volte. Troverete un sacco di informazioni in StackOverflow. Inoltre, OWASP sito web ha un XSS prevenzione cheat sheet che si dovrebbe passare attraverso.

    Sulle librerie da usare, OWASP è ESAPI biblioteca ha una java sapore. Si dovrebbe provare che fuori. Inoltre, ogni quadro che si utilizza ha un certo grado di protezione contro XSS. Di nuovo, OWASP sito ha informazioni su quadri più popolari, così mi consiglia di passare attraverso il loro sito.

  3. 11

    Ho avuto grande fortuna con OWASP Anti-Samy e un AspectJ consulente di tutta la mia Primavera Controller che blocca XSS da ottenere.

    public class UserInputSanitizer {
    
        private static Policy policy;
        private static AntiSamy antiSamy;
    
        private static AntiSamy getAntiSamy() throws PolicyException  {
            if (antiSamy == null) {
                policy = getPolicy("evocatus-default");
                antiSamy = new AntiSamy();
            }
            return antiSamy;
    
        }
    
        public static String sanitize(String input) {
            CleanResults cr;
            try {
                cr = getAntiSamy().scan(input, policy);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
            return cr.getCleanHTML();
        }
    
        private static Policy getPolicy(String name) throws PolicyException {
            Policy policy = 
                Policy.getInstance(Policy.class.getResourceAsStream("/META-INF/antisamy/" + name + ".xml"));
            return policy;
        }
    
    }

    Si può ottenere il AspectJ advisor dal questo post stackoverflow

    Penso che questo sia un approccio migliore e poi c:out particolare se si fanno un sacco di javascript.

    • La prassi normale è di HTML-fuga qualsiasi utente controllato di dati durante la visualizzazione, non durante l’elaborazione dei dati presentati in servlet, né durante la memorizzazione nel DB. 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. Il codice di affari e DB sono di volta in volta non sensibili per XSS. Solo la vista. Si deve poi sfuggire solo a destra c’è in vista.
    • Sì e no. Anche se la pratica generale è quello di fuggire in mostra ci sono molte ragioni si potrebbe desiderare per igienizzare a scrivere. Ci sono alcuni casi in cui si desidera agli utenti di inserire un sottoinsieme di HTML e, anche se si può sterilizzare sul display, questo è in realtà piuttosto lento e anche fonte di confusione per gli utenti. La seconda, se condividere i dati con servizi 3rd party come Api esterne questi servizi può o non può fare una corretta sanificazione stessi.
    • come me e voi, sia detto, la “prassi normale” è quello di fuggire sul display. Quello che hai detto in voi il commento di cui sopra sono più specifici casi d’uso e, quindi, sarebbe piacevolmente richiedono soluzioni specifiche.
    • Sì, forse avrei dovuto fare il mio caso d’uso più chiaro. Io lavoro principalmente di gestione dei contenuti (modifica HTML) cose.
  4. 7

    Gestione XSS richiede più convalide, dati dal lato client.

    1. Ingresso Convalide (modulo di validazione lato Server. Ci sono diversi modi per andare su di esso. Puoi provare a JSR 303 bean validation(sospensione validator), o ESAPI Ingresso framework di Validazione. Anche se non ho provato io stesso (ancora), c’è un’annotazione che i controlli per la sicurezza di html (@SafeHtml). Si potrebbe infatti utilizzare Sospensione validatore con Spring MVC, per bean convalide -> Rif
    2. In fuga le richieste di URL – Per tutte le vostre richieste HTTP, utilizzare un qualche tipo di filtro XSS. Ho usato il seguente per la nostra web app e si prende cura di ripulire l’URL HTTP request – http://www.servletsuite.com/servlets/xssflt.htm
    3. Fuga di dati/html restituito al client (vedi sopra: @BalusC spiegazione).
  5. 3

    Vorrei suggerire regolarmente test di vulnerabilità utilizzando uno strumento automatico e fissaggio quello che trova. È molto più facile suggerire una biblioteca per aiutare con una specifica vulnerabilità, allora per tutti gli attacchi XSS in generale.

    Skipfish è uno strumento open source di Google che ho indagato, che si trova un sacco di roba, e sembra che vale la pena utilizzare.

    • Prevenire è meglio che la diagnosi (es. skipfish) e la successiva quick-fix.
    • Io non sono d’accordo. Prevenzione, senza la diagnosi è solo un dogma. Eseguire la diagnosi come parte della vostra IC ciclo per evitare il “quick fix” problema.
  6. 3

    Non è di facile e pronta soluzione contro XSS. La OWASP ESAPI API ha un supporto per la fuga che è molto utile, e hanno librerie di tag.

    Il mio approccio è stato, sostanzialmente, di estendere il stuts 2 tag in modi seguenti.

    1. Modificare s:etichetta di proprietà, in modo che possano attributi extra affermando che tipo di escape è necessaria (escapeHtmlAttribute=”true” etc.). Questo comporta la creazione di una nuova Proprietà e PropertyTag classi. La classe utilizza OWASP ESAPI api per la fuga.
    2. Cambiare freemarker modelli per utilizzare la nuova versione di s:proprietà e impostare la fuga.

    Se non si desidera modificare le classi nel passaggio 1, un altro approccio sarebbe quello di importare il ESAPI tag nel freemarker modelli e fuga come necessario. Quindi se avete bisogno di usare un s:proprietà tag nella pagina JSP, avvolgerlo con e ESAPI tag.

    Ho scritto una spiegazione più dettagliata qui.

    http://www.nutshellsoftware.org/software/securing-struts-2-using-esapi-part-1-securing-outputs/

    Sono d’accordo fuga ingressi non è l’ideale.

  7. 2

    La mia personale opinione è che si dovrebbe evitare l’uso di JSP/ASP/PHP/etc pagine. Invece l’uscita di API simili a SAX (solo per chiamare, piuttosto che di gestione). In questo modo non vi è un singolo strato che deve creare il formato di output.

  8. 2

    Se si desidera automaticamente fuga tutti JSP variabili senza dover esplicitamente avvolgere ogni variabile, è possibile utilizzare un EL resolver dettagli qui) con il codice sorgente completo e un esempio (JSP 2.0 o versione più recente), e discusso in maggiore dettaglio qui:

    Per esempio, attraverso l’utilizzo di cui sopra EL resolver, il codice JSP rimarrà così, ma ogni variabile verrà automaticamente sfuggiti per il resolver

    ...
    <c:forEach items="${orders}" var="item">
      <p>${item.name}</p>
      <p>${item.price}</p>
      <p>${item.description}</p>
    </c:forEach>
    ...

    Se si desidera forzare la fuga per impostazione predefinita, in Primavera, si potrebbe prendere in considerazione anche questo, ma non fuggire EL espressioni, solo tag di uscita, penso:

    http://forum.springsource.org/showthread.php?61418-Spring-cross-site-scripting&p=205646#post205646

    Nota: un Altro approccio per EL fuga che utilizza le trasformazioni XSL per la pre-elaborazione di file JSP può essere trovato qui:

    http://therning.org/niklas/2007/09/preprocessing-jsp-files-to-automatically-escape-el-expressions/

Lascia un commento