Des fuites de comptes clients ou des informations liées aux clients fleurissent depuis des années sur le Net. Toutes ne sont pas aussi grosses que celles de Yahoo en 2016, mais peuvent être autant, voire plus, problématiques, surtout si des numéros de cartes bleues ou des mots de passe de comptes en clair sont divulgués.
Par exemple, c’est le cas de la société VTECH, qui en 2015 s’est vu pirater sa base de données de Learning Lodge via une faille de type injection SQL. Les mots de passe récupérés étaient uniquement protégés par un hachage MD5, comme vous avez pu le voir dans le chapitre précédent. Le hachage MD5 n’étant plus un gage de sécurité, il aurait été préférable que les mots de passe soient stockés avec un chiffrement PBKDF2, comme le recommande l’Anssi.
Dans ce chapitre, nous allons voir celle qui dans le Top 10 de 2017 était la première vulnérabilité, mais également la plus fréquente, et qui passe en troisième position dans le Top 10 de 2021 : l’injection. Nous verrons quels sont les types d’injection et comment s’en prémunir.
Découvrez l'injection
Cette vulnérabilité permet à un attaquant d’injecter des données non maîtrisées qui seront exécutées par l’application et qui permettent d’effectuer des actions qui ne sont normalement pas autorisées.
Ces injections peuvent être des requêtes SQL, par exemple pour manipuler la base de données, du code JavaScript ou HTML.
L'injection SQL est l’attaque par injection la plus connue. Dans le cas d’une attaque par injection SQL, au lieu de mettre un nom d'utilisateur et un mot de passe sur une page de connexion, un utilisateur malveillant entrera des données directement interprétées par le moteur SQL, ce qui lui permettra de modifier le comportement de l’application.
Sécurisez une application contre l’injection SQL
Pour garantir une protection contre l’injection SQL, il est possible d’utiliser un pare-feu d'application web ou WAF, pour Web Application Firewall en anglais. Ce pare-feu se place entre l'utilisateur et l’application web et permet de vérifier et d'intercepter les données envoyées. Toutefois il est également possible de sécuriser l’application directement dans le code.
Validez les entrées
La validation des entrées est une excellente pratique en tant que développeur web. Elle limite ce que l'utilisateur peut mettre dans la zone de texte. Avez-vous déjà été frustré lors de la création d'un compte parce qu'il n'était pas possible de créer un mot de passe sans chiffres ou lettres majuscules ?
C'est parce que la validation des entrées a été implémentée : l'entrée est analysée après avoir appuyé sur Entrée. Cela n'empêchera pas l'injection, mais c'est une mesure que vous pouvez mettre en place pour limiter des attaques de base. En effet, les caractères spéciaux spécifiques à certains langages ne pourront pas être utilisés.
Quels types de caractères peut-on limiter lors de la saisie utilisateur ?
Si vous avez dit le signe égal et l'apostrophe, vous êtes sur la bonne voie ! En effet, ces caractères sont interprétés par le moteur de base de données, ce qui veut dire que si un attaquant peut les entrer dans un champ, ils pourront potentiellement altérer le fonctionnement ; c’est le principe d’une injection SQL.
Paramétrez vos variables
Vous pouvez écrire vos requêtes SQL en paramétrant les variables. C'est ce qu'on appelle une requête préparée.
Il existe de nombreuses façons de sécuriser les requêtes SQL, mais comme la requête ne se connecte pas directement à la base de données, une requête préparée est l'une des meilleures pratiques pour sécuriser vos données contre l'injection SQL. Les langages Java, .NET, ColdFusion, PHP et Ruby ont également des fonctions intégrées pour paramétrer vos variables.
Utilisez un Object Relational Mapper (ORM)
De nombreux langages disposent d'outils ORM (Object Relational Mapper) qui peuvent obfusquer votre requête. Cela signifie qu'il masque ce à quoi ressemble vraiment la requête SQL, ce qui permet d’ajouter une couche de sécurité supplémentaire.
Définissez le cross-site scripting
Depuis 2021, la catégorie injection inclut également les failles de cross-site scripting.
Les attaques cross-site scripting ou XSS sont faites pour prendre le contrôle de votre navigateur. Un attaquant qui y parvient aura potentiellement accès à vos cookies et à vos sessions qui peuvent contenir des données sensibles ! Ces attaques peuvent également permettre d’apporter des modifications non autorisées à une application web et créer des liens qui vous mèneront vers des sites malveillants.
Découvrez les attaques utilisant XSS
Avec une attaque XSS, un attaquant va essayer de prendre le contrôle de votre navigateur en injectant un script JavaScript dans l'application web. Il pourra l’injecter directement dans un formulaire, mais il peut également l’injecter dans l'URL, l'en-tête HTTP ou d'autres parties du framework utilisé.
Contrairement aux injections SQL, il ne s'agit pas de requêtes et de commandes SQL sur une base de données. Une faille XSS s’exécute dans le code de l'application web et cible l'utilisateur de l'application web plutôt que l'application web ou son infrastructure.
On distingue deux grandes familles d’attaques XSS :
les XSS stockées, où l’attaquant réussit à injecter son script dans l’application web ou sa base de données ;
les XSS réfléchies, où l’attaquant doit faire cliquer la victime sur un lien préparé par ses soins.
Pour une attaque de type XSS stockée, imaginez une page d’inscription avec le nom d'utilisateur et le mot de passe. Au lieu du nom d'utilisateur, le pirate va entrer un code HTML exécutant du code JavaScript, par exemple :
alert(“XSS”);
Sur une autre page du site, on peut voir la liste des utilisateurs. Toute personne visitant cette page exécutera le code JavaScript de l’attaquant.
Pour une attaque de type XSS réfléchie, imaginez une page qui affiche le titre contenu dans un paramètre d’URL, par exemple :
https://example.org/page?titre=Bienvenue
Un attaquant pourra envoyer un lien à une victime avec l’adresse suivante :
https://example.org/page?titre=<script>alert(“XSS”);</script>
Cette attaque est plus difficile à exploiter, car il faut convaincre la victime de cliquer sur le lien, mais elle est aussi plus discrète, car il n’y a pas de traces du script malveillant dans l’application web ou sa base de données.
Ces techniques permettent d’exécuter du code arbitraire dans le navigateur de la victime.
Les attaques XSS ciblent également les cookies, ce qui permet à un attaquant de faire envoyer, par le navigateur de la victime, une copie du cookie de session obtenu après une authentification réussie à l’attaquant, qui pourra ainsi voler la session de la victime.
Pour s’en prémunir, il convient de “purifier” (ou nettoyer) toutes les données soumises par l’utilisateur de l’application web, afin de s’assurer qu’elles ne seront jamais interprétées comme du code HTML ou JavaScript. Il existe des bibliothèques adaptées à cette fonction dans tous les langages comme DOMPurify en JavaScript ou HTMLPurifier en PHP.
En résumé
Les injections peuvent inclure (mais sans s'y limiter) des commandes SQL, JavaScript, HTML ou OS et permettent de manipuler les entrées pour effectuer des actions et accéder à des données normalement non autorisées.
Vous pouvez prévenir les attaques par injection en sécurisant votre code avec la validation des entrées, les variables paramétrées, les ORM et les procédures SQL stockées. Et pensez à utiliser la fonction executesql() dans la base de données.
Le Cross-site Scripting est une famille d’attaque côté client et non côté serveur.
Empêcher une faille XSS avec validation de l'entrée et un encodage de l'entrée.
Nous venons de voir comment se prémunir contre les injections et les failles XSS ; dans le prochain chapitre, nous verrons comment sécuriser une application dès sa conception.
