XSS-Verhinderung in JSP/Servlet-Webanwendung

Wie kann ich XSS-Angriffe in einer JSP/Servlet-Webanwendung verhindern?

XSS kann in JSP mit verhindert werden JSTL <c:out> Etikett bzw fn:escapeXml() EL-Funktion bei (erneuter) Anzeige benutzergesteuerte Eingabe. Dazu gehören Anforderungsparameter, Header, Cookies, URL, Text usw. Alles, was Sie aus dem Anforderungsobjekt extrahieren. Auch die benutzergesteuerte Eingabe von früheren Anfragen, die in einer Datenbank gespeichert sind, muss während der erneuten Anzeige maskiert werden.

Zum Beispiel:

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

Dadurch werden Zeichen maskiert, die das gerenderte HTML wie z <, >, ", ' und & hinein HTML/XML-Entitäten wie zum Beispiel <, >, ", ' und &.

Beachten Sie, dass Sie sie im Java-Code (Servlet) nicht maskieren müssen, da sie dort drüben harmlos sind. Einige können sich dafür entscheiden, ihnen währenddessen zu entkommen Anfrage Verarbeitung (wie Sie es in Servlet oder Filter tun) statt Antwort Verarbeitung (wie Sie es in JSP tun), aber auf diese Weise riskieren Sie, dass die Daten unnötigerweise doppelt maskiert werden (z & wird & anstatt & und letztendlich würde der Endbenutzer sehen & dargestellt werden) oder dass die in der DB gespeicherten Daten nicht mehr portierbar sind (z. B. beim Exportieren von Daten in JSON, CSV, XLS, PDF usw., für die überhaupt kein HTML-Escape erforderlich ist). Sie verlieren auch die soziale Kontrolle, weil Sie nicht mehr wissen, was der Benutzer tatsächlich ausgefüllt hat. Als Site-Administrator möchten Sie wirklich gerne wissen, welche Benutzer/IPs versuchen, XSS auszuführen, damit Sie sie einfach nachverfolgen können sie und ergreifen Sie entsprechende Maßnahmen. Escaping während der Request-Verarbeitung sollte nur als letztes Mittel eingesetzt werden, wenn es wirklich darum geht, ein Zugunglück einer schlecht entwickelten Legacy-Webanwendung in kürzester Zeit zu beheben. Dennoch sollten Sie Ihre JSP-Dateien letztendlich so umschreiben, dass sie XSS-sicher werden.

Wenn Sie benutzergesteuerte Eingaben erneut als HTML anzeigen möchten, wobei Sie nur eine bestimmte Teilmenge von HTML-Tags zulassen möchten, z <b>, <i>, <u>usw., dann müssen Sie die Eingabe durch eine Whitelist bereinigen. Sie können einen HTML-Parser wie verwenden Jsuppe dafür. Viel besser ist es jedoch, eine menschenfreundliche Auszeichnungssprache wie Markdown (auch hier bei Stack Overflow verwendet) einzuführen. Dann können Sie einen Markdown-Parser wie verwenden Commonmark dafür. Es hat auch eingebaute HTML-Bereinigungsfunktionen. Siehe auch Markdown oder HTML.

Die einzige Sorge auf der Serverseite in Bezug auf Datenbanken ist SQL-Injektion Verhütung. Sie müssen sicherstellen, dass Sie benutzergesteuerte Eingaben niemals direkt in der SQL- oder JPQL-Abfrage mit Zeichenfolgen verketten und dass Sie durchgehend parametrisierte Abfragen verwenden. In JDBC-Begriffen bedeutet dies, dass Sie verwenden sollten PreparedStatement anstatt Statement. Verwenden Sie in JPA-Begriffen Query.

Eine Alternative wäre die Migration von JSP/Servlet zum MVC-Framework JSF von Java EE. Es hat überall eingebaute XSS (und CSRF!) Prävention. Siehe auch CSRF-, XSS- und SQL-Injection-Angriffsschutz in JSF.

Das How-to-prevent-xss wurde mehrfach gefragt. In StackOverflow finden Sie viele Informationen. Ebenfalls, Die OWASP-Website verfügt über einen XSS-Präventions-Spickzettel die du durchmachen sollst.

Zu den zu verwendenden Bibliotheken, Die ESAPI-Bibliothek von OWASP hat einen Java-Geschmack. Das solltest du ausprobieren. Abgesehen davon hat jedes Framework, das Sie verwenden, einen gewissen Schutz gegen XSS. Auch hier enthält die OWASP-Website Informationen zu den beliebtesten Frameworks, daher würde ich empfehlen, ihre Website durchzugehen.

Ich hatte großes Glück mit OWASP Anti-Samy und einem AspectJ Advisor auf allen meinen Spring Controllern, der XSS daran hindert, hineinzukommen.

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;
    }

}

Sie können den AspectJ Advisor aus diesem Stackoverflow-Post abrufen

Ich denke, das ist ein besserer Ansatz als c:out, insbesondere wenn Sie viel Javascript verwenden.

Die Verwaltung von XSS erfordert mehrere Validierungen, Daten von der Clientseite.

1. Eingabevalidierungen (Formularvalidierung) auf der Serverseite. Es gibt mehrere Möglichkeiten, dies zu tun. Sie können die JSR 303-Bean-Validierung versuchen (Validator in den Ruhezustand versetzen), oder ESAPI Input Validation Framework. Obwohl ich es (noch) nicht selbst ausprobiert habe, gibt es eine Anmerkung, die nach sicherem HTML sucht (@SafeHtml). Sie könnten tatsächlich den Hibernate-Validator mit Spring MVC für Bean-Validierungen verwenden -> Ref
2. URL-Anfragen maskieren – Verwenden Sie für alle Ihre HTTP-Anforderungen eine Art XSS-Filter. Ich habe Folgendes für unsere Web-App verwendet und es kümmert sich um die Bereinigung der HTTP-URL-Anforderung – http://www.servletsuite.com/servlets/xssflt.htm
3. Daten/html entkommen an den Client zurückgegeben (siehe oben @BalusC-Erklärung).

Ich würde vorschlagen, regelmäßig mit einem automatisierten Tool auf Schwachstellen zu testen und alles zu beheben, was es findet. Es ist viel einfacher, eine Bibliothek vorzuschlagen, die bei einer bestimmten Schwachstelle hilft, als für alle XSS-Angriffe im Allgemeinen.

Skipfish ist ein Open-Source-Tool von Google, das ich untersucht habe: Es findet ziemlich viel Zeug und scheint es wert zu sein, verwendet zu werden.

Es gibt keine einfache, sofort einsatzbereite Lösung gegen XSS. Die OWASP ESAPI API hat etwas Unterstützung für das Escaping, was sehr nützlich ist, und sie hat Tag-Bibliotheken.

Mein Ansatz bestand im Grunde darin, die stuts 2-Tags auf folgende Weise zu erweitern.

1. Ändern Sie das s:property-Tag, damit es zusätzliche Attribute annehmen kann, die angeben, welche Art von Escapezeichen erforderlich ist (escapeHtmlAttribute=”true” usw.). Dazu gehört das Erstellen einer neuen Property- und PropertyTag-Klasse. Die Property-Klasse verwendet OWASP ESAPI API für das Escaping.
2. Ändern Sie die Freemarker-Vorlagen, um die neue Version von s:property zu verwenden, und legen Sie das Escaping fest.

Wenn Sie die Klassen in Schritt 1 nicht ändern möchten, besteht ein anderer Ansatz darin, die ESAPI-Tags in die Freemarker-Vorlagen zu importieren und bei Bedarf zu entkommen. Wenn Sie dann das as:property-Tag in Ihrer JSP verwenden müssen, umschließen Sie es mit einem ESAPI-Tag.

Eine ausführlichere Erklärung habe ich hier geschrieben.

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

Ich stimme zu, Eingaben zu entkommen, ist nicht ideal.

Meine persönliche Meinung ist, dass Sie die Verwendung von JSP/ASP/PHP/etc-Seiten vermeiden sollten. Geben Sie stattdessen an eine SAX-ähnliche API aus (nur zum Aufrufen und nicht zum Verarbeiten). Auf diese Weise gibt es eine einzelne Schicht, die eine wohlgeformte Ausgabe erzeugen muss.