web-dev-qa-db-fra.com

Prévention XSS dans l'application Web JSP / Servlet

Comment puis-je prévenir les attaques XSS dans une application Web JSP/Servlet?

javasecurityjspservletsxss
66
newbie

Il est possible d’empêcher XSS dans JSP en utilisant la balise [~ # ~] jstl [~ # ~]<c:out> ou fn:escapeXml() fonction EL lorsque (ré) affiche une entrée contrôlée par l'utilisateur . Cela inclut les paramètres de requête, les en-têtes, les cookies, l'URL, le corps, etc. Tout ce que vous extrayez de l'objet de requête. De plus, les entrées contrôlées par l'utilisateur issues de requêtes précédentes qui sont stockées dans une base de données doivent être ignorées pendant le réaffichage.

Par exemple:

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

Cela échappera aux caractères susceptibles de malformer le code HTML rendu, tels que <, >, ", ' Et & En Entités HTML/XML telles que &lt;, &gt;, &quot;, &apos; Et &amp;.

Notez qu'il n'est pas nécessaire de leur échapper dans le code Java (Servlet), car ils sont inoffensifs là-bas. Certains peuvent choisir de les échapper lors de demande traitement (comme vous le faites dans Servlet ou Filtre) au lieu de réponse traitement (comme dans JSP), mais vous risqueriez de perdre inutilement les données dans les données (par exemple, & devient &amp;amp; au lieu de &amp; et l'utilisateur final verrait que &amp; était présenté) , ou que les données stockées dans la base de données deviennent impossibles à importer (par exemple, lors de l’exportation de données au format JSON, CSV, XLS, PDF, etc., ce qui ne nécessite pas l’échappement de code HTML). Vous perdrez également le contrôle social, car vous ne savez plus ce que l'utilisateur a réellement renseigné. En tant qu'administrateur de site, vous souhaitez vraiment savoir quels utilisateurs/adresses IP essaient d'exécuter XSS afin de pouvoir facilement suivre et agissez en conséquence. Les échappées pendant le traitement des demandes ne devraient être utilisées que comme dernier recours lorsque vous avez vraiment besoin de réparer dans les plus brefs délais l'épave d'une application Web héritée mal développée. Néanmoins, vous devriez en fin de compte réécrire vos fichiers JSP pour qu'ils soient compatibles XSS.

Si vous souhaitez afficher à nouveau les entrées contrôlées par l'utilisateur au format HTML, dans lesquelles vous souhaitez autoriser uniquement un sous-ensemble spécifique de balises HTML telles que <b>, <i>, <u>, Etc., vous devez ensuite assainir l’entrée par une liste blanche. Vous pouvez utiliser un analyseur HTML tel que Jsoup . Cependant, il est préférable d’introduire un langage de balisage convivial, tel que Markdown (également utilisé ici dans Stack Overflow). Ensuite, vous pouvez utiliser un analyseur syntaxique Markdown tel que CommonMark . Il a également intégré des fonctionnalités de désinfection HTML. Voir aussi Je recherche un encodeur HTML Java _ .

La seule préoccupation du côté serveur en ce qui concerne les bases de données est la prévention de injection SQL . Vous devez vous assurer de ne jamais concaténer par une chaîne une entrée contrôlée par l'utilisateur directement dans la requête SQL ou JPQL et que vous utilisez des requêtes paramétrées jusqu'au bout. En termes JDBC, cela signifie que vous devez utiliser PreparedStatement au lieu de Statement. En termes JPA, utilisez Query .

Une alternative serait de migrer de JSP/Servlet vers le framework MVC de Java EE [~ # ~] jsf [~ # ~] . Il intègre la prévention XSS (et CSRF!) Partout. Voir aussi Prévention des attaques par injection CSRF, XSS et SQL dans JSF .

94
BalusC

How-to-prevent-xss a été demandé à plusieurs reprises. Vous trouverez beaucoup d'informations dans StackOverflow. En outre, site Web OWASP a une feuille de triche de prévention XSS que vous devriez passer.

Sur les bibliothèques à utiliser, bibliothèque ESAPI de OWASP a Java. Vous devriez l'essayer. De plus, chaque framework que vous utilisez possède une certaine protection contre XSS. Encore une fois, le site Web de l'OWASP contient des informations sur les cadres les plus populaires, je vous recommande donc de consulter leur site.

12
Sripathi Krishnan

J'ai eu beaucoup de chance avec OWASP Anti-Samy et un conseiller AspectJ sur tous mes contrôleurs Spring qui empêchent XSS d'entrer.

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

}

Vous pouvez obtenir le conseiller AspectJ auprès de la cet article stackoverflow

Je pense que c est une meilleure approche que c: en particulier si vous utilisez beaucoup de javascript.

12
Adam Gent

La gestion de XSS nécessite plusieurs validations, les données côté client.

  1. Validations en entrée (validation du formulaire) côté serveur. Il y a plusieurs façons de s'y prendre. Vous pouvez essayer la validation de bean JSR 303 ( validateur d'hibernation ) ou cadre de validation d'entrée ESAPI . Bien que je ne l'aie pas encore essayé (il l'est moi-même), il existe une annotation qui vérifie la sécurité du code html (@ SafeHtml) . Vous pouvez en fait utiliser le validateur Hibernate avec Spring MVC pour les validations de beans -> Ref
  2. Échapper aux demandes d'URL - Pour toutes vos demandes HTTP, utilisez une sorte de filtre XSS. J'ai utilisé ce qui suit pour notre application Web et il s'occupe de nettoyer la demande d'URL HTTP - http://www.servletsuite.com/servlets/xssflt.htm
  3. Échappement data/html renvoyé au client (voir ci-dessus l'explication @BalusC).
7
MasterV

Il n’existe pas de solution simple, prête à utiliser, contre XSS. L'API ESAPI OWASP prend en charge l'échappement qui est très utile, et ils ont des bibliothèques de balises.

Mon approche consistait essentiellement à étendre les balises stuts 2 de la manière suivante.

  1. Modifiez la balise s: property afin de pouvoir prendre des attributs supplémentaires indiquant le type d'échappement requis (escapeHtmlAttribute = "true", etc.). Cela implique la création de nouvelles classes Property et PropertyTag. La classe Property utilise l’API OWASP ESAPI pour l’échappement.
  2. Modifiez les modèles de libraire pour qu'ils utilisent la nouvelle version de la propriété s: et définissez l'échappement.

Si vous ne souhaitez pas modifier les classes à l'étape 1, une autre approche consiste à importer les balises ESAPI dans les modèles freemarker et à les quitter en cas de besoin. Ensuite, si vous devez utiliser une balise s: property dans votre JSP, enveloppez-la avec une balise ESAPI.

J'ai écrit une explication plus détaillée ici.

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

Je conviens que s'échapper des entrées n'est pas idéal.

3
brett.carr

Je suggérerais de tester régulièrement les vulnérabilités à l'aide d'un outil automatisé et de corriger tout ce qu'il trouve. Il est beaucoup plus facile de suggérer une bibliothèque pour aider avec une vulnérabilité spécifique que pour toutes les attaques XSS en général.

Skipfish est un outil open source de Google sur lequel j'ai étudié: il trouve pas mal de fichiers et semble valoir la peine d'être utilisé.

3
Sean Reilly

Mon opinion personnelle est d’éviter d’utiliser les pages JSP/ASP/PHP/etc. Exportez plutôt vers une API similaire à SAX (conçue uniquement pour appeler plutôt que pour gérer). De cette façon, une seule couche doit créer une sortie bien formée.

2
Tom Hawtin - tackline

Si vous souhaitez échapper automatiquement toutes les variables JSP sans avoir à envelopper explicitement chaque variable, vous pouvez utiliser un résolveur EL comme détaillé ici source et un exemple (JSP 2.0 ou plus récent) , et discuté plus en détail ici :

Par exemple, en utilisant le résolveur EL mentionné ci-dessus, votre code JSP restera tel quel, mais chaque variable sera automatiquement échappée par le résolveur.

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

Si vous voulez forcer l'échappement par défaut dans Spring, vous pouvez également considérer cela, mais cela n'échappera pas aux expressions EL, mais simplement à la sortie des balises, je pense:

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

Remarque: Une autre approche de l'échappement EL utilisant des transformations XSL pour le prétraitement des fichiers JSP est disponible ici:

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

2
Brad Parks