Dans la continuité de notre série dédiée à la compréhension des vulnérabilités web, ce 6ème épisode nous parle d’exposition de données sensibles.
Comme pour les autres articles de cette série, nous ne plongerons pas des les détails techniques (il faudrait y consacrer un nombre conséquent de pages), nous ne parlerons donc pas de Cryptographie.
Ce type de vulnérabilité est classé au sixième rang de l’OWASP Top 10 2013. Ces vulnérabilités sont assez difficiles à exploiter par les pirates; mais l’impact est tellement sévère qu’il est très important de correctement les comprendre et de faire des choix d’architecture appropriés.
Nous pouvons distinguer deux types de données :
- les données stockées
- les données qui transitent (en interne entre serveurs, ou vers/depuis les navigateurs web)
Dans les deux cas, des problèmes se présentent lorsque des données sensibles (banque, santé, données personnelles…) ne sont pas suffisamment protégées:
- transmises ou stockées en clair (non cryptées / hachées)
- cryptées ou hachées avec un algorithme faible
Ce qu’il faut considérer avant toute chose, est qu’un pirate tentera les approches suivantes:
- décrypter des données stockées sur un serveur (précédemment volées via d’autres types de vulnérabilités)
- intercepter des données entre le serveur et le navigateur web (ou entre serveurs)
- essayer de tromper l’application web pour au final effectuer différentes actions : modifier le contenu d’un panier de site e-commerce, ou obtenir des droits plus élevés sur une application.
Prenons un exemple simple :
Un pirate attaque votre serveur via par exemple une faille de type injection SQL (sujet du premier article de cette série, à propos des injections), et récupère ainsi tout ou partie de votre base de données. Cette base de données contient l’ensemble des mots de passe de tous vos consommateurs. Malheureusement, les mots de passe ont été hachés avec un algorithme dépassé (tel que “MD5”). L’attaquant va pouvoir utiliser ce que l’on appelle des “rainbow tables”, permettant de faire la correspondance entre des valeurs déjà hachés avec MD5 et les valeurs en clair. Vous pouvez être certains que la majorité des mots de passe seront exploités.
Autre exemple:
Vous ne protégez pas les pages authentifiées de votre site (celles où l’utilisateur est connecté) avec HTTPS (SSL/TLS), ou avec une vieille version d’HTTPS. En “sniffant” le traffic Internet, les attaquants vont pouvoir très facilement observer toutes les données transitant sur le site Internet, y compris toute donnée sensible (informations de cartes de crédit, logins, mots de passe…).
Comment éviter de telles vulnérabilités?
1. La première étape est de ne pas collecter d’informations auprès des utilisateurs, que vous n’utiliserez pas. Il en va de même pour le stockage des données: ne pas stocker d’informations que vous n’avez pas besoin de stocker. Si elles ne sont pas présentes, les informations ne pourront pas être volées!
Cela peut semble facile, et ça l’est. Durant la conception fonctionnelle et technique, prenez assez de temps pour évaluer les besoins de collecte/stockage.
2. Identifier les données sensibles, et s’assurer qu’elles sont cryptées avec l’algorithme adéquat, lors de la transmission et lors du stockage.
3. S’assurer que des algorithmes récents et reconnus sont utilisés pour crypter/hacher les données.
L’OWASP et de nombreuses autres sources d’informations répertorient ces algorithmes.
4. Effectuer un test d’intrusion sur votre application web, pour être certain de ne pas avoir oublié quoi que ce soit. Périodiquement soumettre votre application web à un audit de sécurité permettra de s’assurer que l’application reste suffisamment robuste au fil du temps.
Si vous souhaitez poursuivre plus en profondeur dans ce sujet, je vous recommande les 3 cheat sheets suivantes (vous aurez besoin de connaissances techniques) :
OWASP Cryptographic Storage Cheat Sheet
OWASP Password Storage Cheat Sheet
OWASP Transport Layer Protection Cheat Sheet