Go to Hackademy website

Sécurité des applications web : pourquoi devez-vous vous en soucier ?

Nicolas Mérouze

Posté par Nicolas Mérouze dans les catégories sécurité

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.

Pourtant l'impact sur l'activité commerciale mais aussi sur le reste de l'entreprise d'une attaque est considérable !

Il est impératif de mettre la priorité sur la sécurité des applications web et d'y allouer le budget nécessaire.

Défense vs attaque

La sécurité web en chiffres

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.

Types de vulnérabilité

Comment éviter d'être pris pour cible ?

Authentification

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 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.

Télécharger le guide ultime pour réussir votre application web métier

Contrôle d'accès

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.

Injection

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.

XSS

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.

Faille de sécurité

Transmission de données

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.

Configuration

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.

Composants externes

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.

Logs

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.

Audits, tests de pénétration et DevSecOps

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.

Conclusion

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.

Télécharger le guide ultime pour réussir votre application web métier

Articles connexes

Développement d'application web : 10 conseils pour choisir la bonne agence

30/07/2019

Choisir la bonne agence pour développer votre application web n’est pas une chose aisée. Il n’y a pas de méthode précise.

Applications web et transformation digitale : préparez le terrain avec la conduite du changement

23/07/2019

La transformation numérique intervient partout dans les entreprises et nécessite de faire appel à de nouveaux outils et applications.

Développement d'application web métier : 7 raisons pour lesquelles votre projet va échouer

16/07/2019

Moins d’un tiers des projets d’applications se terminent dans les temps et sans dépasser le budget. C’est une statistique à laquelle il faut faire face et être réaliste à son sujet. Ce n’est qu’en...

10 signes que vous devriez procéder à l'audit technique de votre application web

09/07/2019

La qualité de vos applications web est essentielle à la réussite de vos projets. Une mauvaise qualité coûte beaucoup de temps et d'argent. De nombreux signes peuvent vous faire réaliser que vous avez...