Prévenir les attaques XSS dans les applications Java avec Snyk Code

Java est un puissant langage de programmation backend qui peut également servir à créer des pages HTML pour des applications web. Toutefois, les développeurs doivent connaître les risques de sécurité associés aux attaques par cross-site scripting (XSS) lors de la création de ces pages. Avec l’essor des frameworks de templating modernes, il est désormais plus facile de prévenir les attaques grâce à une validation et à un encodage appropriés des entrées. En revanche, lorsque les développeurs créent leurs propres pages HTML sans utiliser de framework de templating, le risque d’introduire des vulnérabilités augmente.

Par exemple, dans une application Spring MVC, l’utilisation de l’objet HttpServletResponse pour écrire directement du contenu dans la réponse peut permettre à des utilisateurs malveillants d’injecter du code dans la page et ainsi provoquer des attaques XSS. Il est donc essentiel que les développeurs prennent des mesures adaptées pour garantir la sécurité de leurs applications web Java et prévenir les vulnérabilités XSS lors de la création de pages HTML.

La solution ci-dessous permet facilement de créer une page rendue côté serveur sans framework spécialisé, qui s’accompagne généralement de consignes spécifiques. Cette méthode présente toutefois certains inconvénients.

Écrire du code HTML dans Spring MVC sans framework de templating

Supposons que vous ayez une application web qui récupère le nom d’un produit et l’affiche sur une page web à l’aide de l’objet HttpServletResponse. Voici comment vous pourriez implémenter cette fonctionnalité dans un contrôleur Spring MVC :

1@GetMapping("/direct")
2public void directLink (@RequestParam String param, HttpServletResponse response) throws IOException {
3   Product prod = productService.getProductByName(param);
4
5   response.setContentType("text/html");
6   var writer = response.getWriter();
7   writer.write(head);
8   writer.write("<div class=\"panel-heading\"><h1>"+ param + "</h1></div>");
9
10   String output = "<div class=\"panel-body\">" +
11           "<ul>" +
12           "<li>%s</li>" +
13           "<li>%s</li>" +
14           "<li>%s</li>" +
15           "</ul>" +
16           "</div>";
17
18   writer.write(String.format(output, prod.getDescription(), prod.getProductType(), prod.getPrice()));
19   writer.write(foot);
20
21   response.getWriter().flush();
22}

Pouvez-vous repérer les types de vulnérabilités de sécurité que le code Java ci-dessus pourrait introduire ?

Détecter les vulnérabilités XSS avec Snyk Code

En examinant attentivement la fonction ci-dessus, vous avez peut-être déjà repéré au moins une vulnérabilité XSS, voire deux. En analysant mon application avec Snyk Code, nous sommes alertés de deux problèmes XSS différents dans cette méthode.

Il existe plusieurs façons d’utiliser Snyk Code. Voyons trois exemples. Le moyen le plus direct de fournir des retours aux développeurs avec Snyk Code consiste à installer un plug-in dans l’IDE. Des plug-ins sont disponibles pour de nombreux IDE. Dans l’exemple suivant, je montre comment le plug-in IntelliJ m’aide à détecter les problèmes XSS pendant le développement.

Résultat du plug-in IntelliJ :

Vous pouvez également exécuter Snyk Code avec la CLI Snyk. En lançant la commande snyk code test dans le terminal, vous obtiendrez un résultat similaire à celui ci-dessous. Cette méthode est pratique sur votre machine locale ou dans le cadre d’une compilation automatisée au sein d’un pipeline CI/CD.

Résultat de la CLI :

La troisième option que je souhaite vous présenter est l’interface web. Pour obtenir ce résultat, j’ai utilisé l’intégration Git avec Snyk et connecté mon dépôt GitHub à l’interface web Snyk depuis le tableau de bord https://app.snyk.io. Cette solution analyse le code enregistré dans mon dépôt à la recherche de vulnérabilités de sécurité.

Résultat de l’interface web :

Les trois méthodes d’analyse révèlent deux problèmes de sécurité XSS distincts à résoudre. Snyk Code indique précisément où ils se trouvent dans mon code. Examinons-les et voyons comment les atténuer.

XSS réfléchie

Une XSS réfléchie est une attaque dans laquelle un utilisateur injecte du code malveillant dans une application web, qui est ensuite renvoyé à l’utilisateur dans une réponse. Dans l’exemple présenté, si les entrées utilisateur n’étaient pas correctement validées ou assainies avant d’être écrites dans la réponse, un utilisateur malveillant pourrait injecter un script qui serait exécuté par toute personne consultant la page web. Ce type d’attaque XSS sert souvent à voler des données utilisateur, à modifier le contenu d’un site web ou à mener d’autres actions malveillantes.

Le code ci-dessus récupère le nom de l’utilisateur dans le paramètre de la requête HTTP, puis l’écrit directement dans l’objet HttpServletResponse à l’aide de :

1writer.write("<div class=\"panel-heading\"><h1>"+ param + "</h1></div>")

Ce code est vulnérable aux attaques XSS, car il ne valide ni n’assainit correctement les entrées utilisateur. Par exemple, un utilisateur malveillant pourrait injecter du code HTML ou JavaScript dans le paramètre « name », qui serait alors exécuté par les personnes consultant la page web.

Par exemple : .../direct?param=<script>alert(document.cookie);</script> pourrait révéler les informations de vos cookies personnels. Cela signifie que ces informations peuvent également être envoyées à un autre serveur à votre insu.

Snyk Code a détecté cette erreur et m’a signalé la vulnérabilité XSS à la ligne 93.

XSS stockée

À l’inverse, une XSS stockée est une attaque dans laquelle le code malveillant est enregistré sur le serveur, puis transmis à tous les utilisateurs qui accèdent à la page concernée. Dans l’exemple présenté, si les entrées utilisateur n’étaient pas correctement validées ou assainies et étaient plutôt stockées dans une base de données, un utilisateur malveillant pourrait injecter un script qui serait transmis à toutes les personnes consultant la page concernée. Ce type d’attaque XSS peut être particulièrement dangereux, car il peut toucher un grand nombre d’utilisateurs et persister même après la correction de l’injection initiale.

Le code ci-dessus récupère un produit depuis ProductService, puis l’affiche dans les champs de la chaîne de sortie. Cependant, ce code est vulnérable aux attaques XSS stockées, car il ne valide ni n’assainit correctement les données provenant de la base de données. L’assainissement est particulièrement important si vous ne savez pas avec certitude qui est autorisé à écrire dans la base de données. Par exemple, un utilisateur malveillant pourrait soumettre une description de produit contenant du code HTML ou JavaScript. Celui-ci serait alors stocké dans la base de données et transmis à toutes les personnes consultant la page du produit.

Snyk Code a signalé ce risque de XSS à la ligne 103, où nous insérons product.description dans la chaîne de sortie sans la valider ni l’assainir.

Atténuer les vulnérabilités XSS avec Snyk Code

Pour prévenir les vulnérabilités XSS, il est important de valider et d’assainir correctement les entrées utilisateur avant de les écrire dans la réponse. Snyk Code nous aide déjà en proposant des solutions possibles. Vous pouvez notamment utiliser une bibliothèque comme Apache Commons Text pour encoder les entrées et empêcher l’exécution de code malveillant.

La fonction escapeHtml4() permet d’échapper le code des XSS réfléchies comme des XSS stockées, afin qu’il ne soit pas exécuté lors du chargement de la page.

D’autres bibliothèques permettent bien sûr d’effectuer un échappement similaire. En plus de Apache Commons Text, vous pouvez consulter OWASP Encoder. Si vous utilisez Spring, vous pouvez également vous servir de HtmlUtils.htmlEscape de Spring.

Avec Apache Commons Text, le code correctement échappé pourrait ressembler à ceci :

1@GetMapping("/direct")
2public void directLink (@RequestParam String param, HttpServletResponse response) throws IOException {
3   Product prod = productService.getProductByName(param);
4
5   response.setContentType("text/html");
6   var writer = response.getWriter();
7   writer.write(head);
8   writer.write("<div class=\"panel-heading\"><h1>"+ StringEscapeUtils.escapeHtml4(param) + "</h1></div>");
9
10   String output = "<div class=\"panel-body\">" +
11           "<ul>" +
12           "<li>%s</li>" +
13           "<li>%s</li>" +
14           "<li>%s</li>" +
15           "</ul>" +
16           "</div>";
17
18   writer.write(String.format(output,
19             StringEscapeUtils.escapeHtml4(prod.getDescription()),
20             StringEscapeUtils.escapeHtml4(prod.getProductType()),
21             StringEscapeUtils.escapeHtml4(prod.getPrice())));
22
23   writer.write(foot);

Utilisez les frameworks de templating avec prudence

Les frameworks de templating comme Thymeleaf peuvent contribuer à protéger contre les vulnérabilités XSS. Thymeleaf est un moteur de templating populaire pour Java qui intègre la prise en charge de l’échappement HTML. Cela aide à prévenir les attaques XSS en encodant toutes les entrées utilisateur intégrées au HTML généré.

Toutefois, tout dépend fortement de la façon dont vous créez le modèle. Par exemple, voici comment vous pourriez utiliser Thymeleaf pour afficher un produit similaire à celui de l’exemple précédent :

1<div class="product" th:each="product : ${products}">
2  <p th:text="${product.name}"></p>
3  <p th:text="${product.type}"></p>
4  <p th:text="${product.pric}"></p>
5  <p th:utext="${product.descriptiont}"></p>
6</div>

Dans cet exemple, les attributs th:text échappent le contenu, contrairement à l’attribut th:utext. Cet attribut th:utext affiche le texte du commentaire sans échapper les balises HTML ni les caractères spéciaux ; il peut donc être vulnérable aux attaques XSS. Lorsque vous utilisez un framework donné, il est essentiel de connaître le comportement de ses différents éléments.

Détecter les vulnérabilités XSS avant le déploiement en production

La prévention des attaques XSS est un enjeu crucial pour les développeurs qui travaillent sur des applications web Java. Il est essentiel de détecter et de corriger les vulnérabilités XSS le plus tôt possible dans le processus de développement. L’assainissement des entrées utilisateur peut atténuer efficacement les attaques XSS, mais il n’est pas toujours suffisant.

Consultez des ressources comme le guide de prévention des XSS de l’OWASP et la leçon de Snyk Learn sur les XSS pour rester au fait des dernières menaces et des bonnes pratiques de prévention des XSS.

Il est également important d’utiliser les bons outils pour détecter les erreurs XSS et les autres problèmes de sécurité avant leur mise en production. Snyk Code est un outil gratuit précieux qui permet de repérer les vulnérabilités potentielles tôt dans le cycle de développement. En adoptant une approche proactive de la prévention des XSS et en utilisant les ressources et les outils adaptés, les développeurs peuvent contribuer à garantir la sécurité et l’intégrité de leurs applications web Java.