81% des entreprises françaises ont été visées par des attaques en 2015. Le coût moyen d'une violation de sécurité est estimé à 800 000 euros. Et pour réparer les dégâts 9 semaines en moyenne sont nécessaires.
La sécurité des applications web est encore plus alarmante. D'après un rapport de Positive Technologies, 100% des applications analysées contiennent des failles de sécurité dont 85% pouvant toucher les utilisateurs.
De plus, d'après le rapport « State of Web Application Vulnerabilities » il y a eu une augmentation de plus de 700% de vulnérabilités entre 2014 et 2018.
Avec le RGPD, il est obligatoire d'informer ses utilisateurs quand l'exploitation d'une brèche se produit. Cette obligation de transparence affecte l'activité commerciale encore plus durement. SERGIC a récemment écopé d'une amende de 400 000 euros pour ne pas avoir été en règle.
Faisons donc le tour des problèmes les plus importants et comment s'en prémunir.
De nombreux problèmes peuvent découler d'une authentification mal implémentée.
Permettre aux utilisateurs d'avoir un mot de passe faible va ouvrir la possibilité aux attaquants d'utiliser des dictionnaires de mots de passe pour s'introduire sur votre application. Le vol de sessions est aussi très courant.
Pour remédier à ces problèmes, de nombreuses solutions existent.
Premièrement, il ne faut accepter que des mots de passe d'une longueur suffisante. 8 est un minimum mais plus est encore mieux. Trop de règles (nombres, majuscules, caractères spéciaux) ne vont pas forcément améliorer la sécurité, les dictionnaires utilisés par les attaquants ayant intégrés ces règles.
Une authentification sans mot de passe est possible. Des entreprises comme Medium ou Slack utilisent la méthode suivante : un utilisateur existant entre son adresse e-mail et reçoit un e-mail avec un lien pour se connecter automatiquement.
Dans ce cas, vous déportez la sécurité de votre authentification aux messageries comme Outlook ou GMail. Ce n'est donc pas une méthode parfaite.
D'autres techniques d'authentification sans mot de passe existent, comme WebAuthn.
Pour améliorer la sécurité de l'authentification, surtout pour des applications web métier avec des données confidentielles, il est recommandé d'utiliser l'authentification à double facteur. Le SMS est à éviter, car il n'est pas assez sûr. Par contre vous pouvez utiliser des méthodes comme Google Authenticator ou Yubikey.
Si un attaquant réussit à devenir administrateur, les conséquences peuvent être catastrophiques ! Mais d'autres problèmes existent. Un service externe non protégé par le contrôle d'accès de l'application et il devient possible de récupérer des données confidentielles en changeant l'URL.
Limiter au maximum les accès de chacun pourra permettre de limiter les risques.
Les faiblesses du contrôle d'accès viennent aussi souvent d'un manque de tests fonctionnels. Cependant il est très complexe pour les développeurs d'écrire tous les tests automatisés nécessaires. C'est pour cela qu'il faut aussi être rigoureux sur les tests manuels.
De nombreuses fonctions dans une application web requièrent des sources de données externes pour fonctionner correctement : paramètres, variables d'environnement, services web, et les données entrées par les utilisateurs.
Si ces données ne sont pas validées, filtrées, ou assainies, on ouvre la porte à de nombreuses vulnérabilités. Les injections SQL sont les plus connues, mais une injection peut se produire au niveau de commandes systèmes, de traitement de fichiers, d'analyse de données, et dans de nombreux autres cas.
Prenons le cas d'une application fictive où l'on peut visualiser le profil d'un utilisateur. Disons que l'ID de l'utilisateur est 123, on accédera au profil avec l'URL suivante : https://app.synbioz.com/users/123. Le serveur fera une requête à la base de données pour faire le rendu du profil.
// req.params["id"] permet d'accéder à l'ID contenu dans l'URL.
const query = "SELECT * FROM users WHERE id = '" + req.params["id"] + "'";
Mais si un utilisateur mal intentionné remplace l'ID dans l'URL par du SQL, la requête pourra être modifiée. Si l'ID devient ' or '1' = '1, la requête SQL deviendra :
SELECT * FROM users WHERE id = '' or '1' = '1';
L'égalité que l'on vient d'injecter est toujours vraie, donc tous les utilisateurs vont être retournés et on pourra utiliser ces données à mauvais escient.
Les injections peuvent causer de la perte, corruption, ou vol de données et peuvent aller jusqu'à la prise de contrôle totale de l'application et du serveur dans le cas de failles sérieuses.
C'est le problème de sécurité numéro 1 pour les applications web. Il est nécessaire d'utiliser des librairies et frameworks qui vont aider à prévenir ces erreurs et de les garder à jour, mais une bonne connaissance des injections est à avoir pour éviter tout problème.
Une faille XSS permet à un attaquant d'insérer du code JavaScript dans l'application si les données utilisateur ne sont pas validées et échappées.
L'attaquant peut alors voler la session, prendre contrôle des comptes, remplacer une partie de l'interface utilisateur, télécharger des logiciels malicieux et bien d'autres encore.
Ce type de faille est simple à exploiter et des outils permet de le faire automatiquement. De plus, deux tiers des applications web contiennent ce problème.
Il est donc essentiel de se protéger. Pour ce faire, de nombreux frameworks existent limitant la possibilité d'avoir un problème XSS. Il faut les privilégier au lieu d'essayer de créer son propre framework.
Transmettre des données en clair est dangereux. Le SSL est obligatoire pour toutes les applications web. Mais le chiffrement est aussi essentiel à tous les niveaux.
Le RGPD requiert que les données des utilisateurs soient chiffrées. Et il faut bien sûr que les informations sensibles stockées en dur soient chiffrées elles aussi.
En plus de veiller à ce que toutes les données et tout flux d'information soient chiffrés, il est aussi essentiel que le chiffrement soit fort.
Pour cela, il faut utiliser les dernières méthodes de chiffrement, comme bcrypt ou PBKDF2, mais aussi éviter de générer des clés de chiffrements faibles.
Une erreur de configuration peut arriver à tous les niveaux : librairies et frameworks de l'application, serveurs, base de données, réseau, services tiers, code, stockage, etc.
De nombreux sites Wordpress et base de données MongoDB en ont été victimes. On laisse la configuration par défaut alors que les paramètres de sécurité sont faibles ou parfois désactivés. Et les attaquants ont des outils pour automatiser la prise de contrôle de ces systèmes.
Il est important de créer des processus et de la documentation. De plus, il faut limiter au maximum le nombre d'outils utilisés pour limiter les fichiers et paramètres de configuration.
Déjà dit en introduction, 94 % des DSI français ont dû renoncer à une mise à jour ou à un correctif de sécurité par peur d'un impact sur l'activité commerciale.
Les failles venant de composants externes avec des vulnérabilités connues sont très courantes. Que ce soit des librairies, des API tierces, ou encore des logiciels comme des bases de données.
Les failles sont diverses dans ce cas et on retrouve un peu toutes celles décrites dans les sections précédentes : injection, XSS, problèmes d'authentification, mauvaise configuration, aucun chiffrement pour la transmission des données, etc. Autant dire que vous vous exposez à un risque critique si vous mettez en pause des mises à jour.
Plus on attend, plus il sera difficile de mettre à jour les dépendances. Il est donc nécessaire de faire un audit des dépendances et des versions régulièrement pour supprimer les dépendances qui ne sont plus utilisées, remplacer les librairies ne recevant plus de mises à jour et être à jour sur le reste.
De nombreux outils existent pour automatiser une partie du travail.
Difficile de détecter une attaque sans monitoring. Sans logs et outils de monitoring, vous êtes assurés de laisser les attaquants faire ce qu'ils veulent sans interruption.
Prenons un exemple. Marriott, chaine d'hôtels, s'est aperçu d'un accès non autorisé sur le système de Starwoods, racheté par Marriott quelques mois avant. Durant l'enquête, ils se sont rendu compte qu'il y a eu des accès non autorisés depuis 2014 et même peut-être avant.
Voilà comment une attaque peut passer inaperçue pendant des années. Un manque de logs, une absence de notifications en cas de détection d'événements suspects ou une mauvaise configuration des outils de monitoring peuvent laisser votre système ouvert pendant une période importante.
Il faut donc s'assurer de logger toutes les tentations de connexion et les erreurs de contrôle d'accès. Mais aussi que les logs soient compatibles avec des solutions qui vous permettent de les parcourir facilement.
Pour s'assurer de la bonne sécurité de votre application web, il est nécessaire de réaliser des tests de pénétration périodiquement. Ces tests évaluent la sécurité de votre application sous plusieurs angles : externe, interne, à l'aveugle et ciblé.
Toutes ces manières permettront de tester tous les cas que l'on peut avoir dans la réalité, contrairement à un audit de sécurité classique qui se concentrera sur une évaluation plus technique.
Pour automatiser les bonnes pratiques de sécurité, on peut aussi intégrer la sécurité au DevOps avec le DevSecOps. Dans ce cas, les personnes responsables du développement et des opérations sont aussi responsables de la sécurité. Cela passe par exemple par l'utilisation d'outils de diagnostics de sécurité dans le processus d'intégration continue.
De nombreuses failles peuvent apparaître à n'importe quel moment, même avec une équipe experte. Le nombre de vecteurs d'attaque est considérable.
Alors que vous devez veiller à ce que tous ces vecteurs soient protégés, un attaquant n'a besoin de ne trouver qu'une seule faille pour vous causer des problèmes.
C'est pour ça qu'il ne faut pas prendre de raccourcis quand il s'agit de sécurité. Tout doit être protégé !
Les audits de sécurité et les tests de pénétration doivent être réguliers, et il est recommandé d'introduire le DevSecOps au plus tôt dans votre projet.
L'équipe Synbioz
Libres d'être ensemble.
