La catégorie A02:2021 se concentre sur les vulnérabilités d'une mise en œuvre inadéquate ou d'une utilisation incorrecte des techniques cryptographiques.
Découvrez un cas d’attaque
En 2012, le monde de la cybersécurité a été secoué par une attaque massive contre LinkedIn, un réseau professionnel en ligne très réputé. Cette attaque est devenue un cas d'étude pour comprendre les risques liés à la sécurité des données sensibles.
L'attaque a impliqué le vol de plusieurs millions de mots de passe d'utilisateurs, qui ont ensuite été publiés sur un forum russe de cybercrimes. L'ampleur de cette brèche de sécurité a mis en lumière plusieurs problématiques majeures, notamment l'importance de chiffrer les données sensibles, en particulier les mots de passe.
L'incident a révélé que LinkedIn utilisait un hachage SHA-1, une méthode de hachage désormais considérée comme obsolète, pour sécuriser les mots de passe. Cette méthode ne comprenait pas de "salage", une technique essentielle qui ajoute une couche supplémentaire de sécurité en mélangeant chaque mot de passe avec un ensemble de caractères aléatoires avant de le hacher.
Le hachage et le salage c’est-à-dire ?
L'absence de salage a rendu les mots de passe vulnérables à des attaques par force brute, où les pirates utilisent des logiciels pour générer rapidement des millions de combinaisons pour déchiffrer les mots de passe. LinkedIn a rapidement pris des mesures pour améliorer sa sécurité, notamment en mettant à jour ses procédures de hachage des mots de passe pour inclure le salage et en renforçant ses politiques de sécurité interne.
Identifiez les attaques sur les données en transit et lors du stockage
Lorsque vous surfez sur Internet, votre navigateur utilise le protocole HTTP (Hypertext Transfer Protocol) pour afficher les pages web et le protocole Transmission Control Protocol/Internet Protocol (TCP/IP) pour les transmettre.
OK. Imaginons que vous tapez une URL dans votre barre de navigateur et que vous cliquez sur Entrée.
Votre navigateur va lancer une connexion TCP, qui va envoyer des requêtes GET et POST pour vous connecter au serveur web associé au nom de domaine ou à l'adresse IP.
Si le serveur web établit la connexion TCP avec le navigateur, une réponse avec le code statut et le fichier demandé (généralement le fichier index.html pour la page web) sera transmise. Mais dans le cas d’une navigation non sécurisée, les données transitent en HTTP et pas en HTTPS…
Le défaut majeur d’HTTP réside dans le fait que les données y transitent en clair, sans chiffrement. Cette caractéristique les rend vulnérables à l'interception et à la manipulation par des tiers non autorisés.
Ceci nous amène à la première vulnérabilité. Les données transitant en HTTP peuvent être interceptées, car elles transitent en clair.
Comment un utilisateur malveillant peut avoir accès à cette connexion TCP ?
L’attaque de l’homme du milieu (MITM)
L'attaque de l'Homme du Milieu (Man-in-the-Middle, en anglais) est l'une des principales causes de détournement de session.
Dans une attaque MITM, l'attaquant intercepte la communication entre deux parties, souvent sans leur connaissance. L'attaquant peut non seulement lire, mais aussi altérer les données échangées. Cette technique est particulièrement efficace contre les communications non sécurisées, telles que celles utilisant HTTP.
Le vol de données et le détournement de session ne sont que quelques exemples de ce qu'un attaquant peut faire une fois sur le réseau. D'une façon ou d'une autre, si les données sont envoyées en HTTP et sont en clair, il suffit de peu d'efforts pour interpréter les données.
Dois-je uniquement protéger les données lors du transit ?
La phase de stockage des données dans une application web est cruciale. Elle implique de stocker des informations dans une base de données, un composant essentiel pour gérer les données des utilisateurs, les paramètres de l'application, et d'autres informations vitales. Cette base de données peut être de différents types :
Relationnelle (comme MySQL ou PostgreSQL),
NoSQL (comme MongoDB),
Ou d'autres formats spécifiques selon les besoins de l'application.
Les données en clair sont des informations stockées ou transmises sans aucun chiffrement. Cela signifie que les informations sont lisibles et compréhensibles par quiconque y accède. Bien que le stockage en clair puisse sembler pratique pour des raisons de performance ou de facilité de développement, il présente des risques de sécurité majeurs.
Stocker des données sensibles, comme les mots de passe, les informations personnelles, ou les détails de carte de crédit en clair, les rend extrêmement vulnérables en cas de brèche de sécurité. Un attaquant accédant à ces données peut les utiliser pour commettre des fraudes, des vols d'identité, ou d'autres actes malveillants.
Imaginons une base de données SQL simple pour un site web, où les informations des utilisateurs sont stockées. Voici un exemple de ce à quoi pourrait ressembler une table de base de données avec des données non hachées :
ID Utilisateur | Nom d'Utilisateur | Mot de Passe |
1 | alice21 | mypassword123 |
2 | bob35 | sunshine48 |
3 | charlie92 | chocolateLover |
Dans cet exemple, les mots de passe sont stockés en clair, c'est-à-dire sans aucune forme de cryptage ou de hachage. Si cette base de données était compromise, un attaquant aurait un accès direct et facile à tous les mots de passe des utilisateurs. Ces données en clair sont une cible de choix pour les cybercriminels, car elles leur permettent de se connecter directement aux comptes des utilisateurs sans effort supplémentaire.
Considérons maintenant la même table, mais cette fois, les mots de passe sont hachés. Voici à quoi cela pourrait ressembler :
ID Utilisateur | Nom d'Utilisateur | Mot de Passe (Haché) |
1 | alice21 | 5f4dcc3b5aa765d61d8327deb882cf99 |
2 | bob35 | a2a551a6458a8de22446cc76d639a9e9 |
3 | charlie92 | 6f1ed002ab5595859014ebf0951522d9 |
Dans cette version, les mots de passe sont transformés en une séquence de caractères apparemment aléatoire, ce qui est le résultat du hachage. Même si un attaquant parvenait à accéder à cette base de données, il lui serait beaucoup plus difficile de retrouver le mot de passe original à partir de ces hachages. Le hachage est une mesure de sécurité essentielle, car il assure que même en cas de fuite de données, les mots de passe restent protégés.
Protégez vos données en transit et lors du stockage
Pour protéger votre application web lors de l’interaction avec vos potentiels clients, il est important de mettre en place HTTPS.
Pour configurer HTTPS sur votre serveur web Apache, suivez ces étapes :
1. Générer un certificat SSL : Vous pouvez obtenir un certificat gratuit via Let's Encrypt ou en générer un certificat auto-signé.
2. Configurer Apache : Modifiez le fichier de configuration d'Apache (par exemple, httpd.conf ou ssl.conf ) pour inclure les lignes suivantes :
<VirtualHost *:443> ServerName www.votresite.com SSLEngine on SSLCertificateFile /chemin/vers/votre/certificat.crt SSLCertificateKeyFile /chemin/vers/votre/private.key SSLCertificateChainFile /chemin/vers/votre/chainfile.pem </VirtualHost>
3. Redémarrer Apache : Après la modification de la configuration, redémarrez le serveur Apache pour appliquer les changements en utilisant la commande sudo systemctl restart apache2 .
Passons désormais à la protection des données lors des phases de stockage.
Je ne veux pas faire la même erreur que LinkedIn, quelles mesures dois-je prendre ?
La protection efficace des données stockées dans une application web passe souvent par l'usage d'algorithmes de hachage. Contrairement au chiffrement, le hachage est une technique non réversible, ce qui signifie qu'une donnée hachée ne peut être retrouvée.
Cela est particulièrement utile pour sécuriser des informations sensibles comme les mots de passe. Prenons un exemple pour illustrer cela. Supposons que vous ayez le mot de passe “Mon Mot 2 passe Privé”.
En utilisant un algorithme de hachage tel que SHA256 ou PBKDF2, ce mot de passe est converti en une empreinte cryptographique, rendant sa lecture impossible pour toute personne non autorisée. Malgré la robustesse de cette méthode, il existe des techniques comme la force brute ou l'utilisation de rainbow tables qui peuvent potentiellement compromettre ces empreintes.
Pour contrer cela, on peut ajouter un "sel" à l'empreinte. Ce sel, une donnée aléatoire ajoutée lors du hachage, renforce la sécurité en rendant chaque empreinte unique.
La mise en œuvre du salage varie selon le langage de programmation utilisé, mais l'idée reste la même : combiner le mot de passe avec une donnée aléatoire avant de le hacher. Il est important de choisir un algorithme de hachage robuste. Des algorithmes comme Bcrypt, Scrypt, Argon2, ou PBKDF2 sont recommandés pour leur sécurité accrue.
En revanche, des algorithmes plus anciens tels que MD5 ou SHA-1 ne sont plus considérés comme sécurisés et doivent être évités.
L’OWASP recommande notamment l’utilisation d'Argon2, tandis que l’Anssi suggère les algorithmes SHA-2 ou SHA-3 pour vérifier l'intégrité des fichiers et PBKDF2 pour le hachage des mots de passe.
En résumé
Les données transmises en HTTP sont vulnérables aux attaques de type Man-in-the-Middle (MITM), où un attaquant peut intercepter et manipuler les données en transit. Il est essentiel de sécuriser les communications avec HTTPS pour protéger les données en transit.
Stocker des données sensibles en clair, comme les mots de passe, dans une base de données expose à des risques de sécurité majeurs en cas de fuite de données. Il est crucial de hacher les mots de passe pour les protéger contre les accès non autorisés.
La mise en place de HTTPS et le hachage sécurisé des mots de passe sont des étapes clés pour protéger les applications web. Il est recommandé d'utiliser des certificats SSL pour HTTPS et de suivre les meilleures pratiques de l'OWASP et de l'Anssi pour le hachage des mots de passe.
Les cheatsheet concernant l'implémentation de TLS et concernant le stockage des mots de passes partagent des astuces utiles pour éviter les défaillances cryptographiques.
Dans le chapitre suivant, "Protégez votre code contre l'injection", nous allons explorer les stratégies pour identifier et prévenir les vulnérabilités d'injection, un des risques de sécurité les plus courants et les plus dangereux dans le développement web.
