Dans cet article, nous parlerons de la conférence Barbus et barbares présentée par François le Droff et Romain Pelisse. Il s’agissait de débattre sur l’audit de sécurité d’une application web JHipster/Spring Boot en couvrant l’ensemble du cycle de vie du logiciel. Cette conférence permettait aux auditeurs de se rendre compte que la sécurité se jouait à tous les niveaux. Ce sujet a bénéficié d’une très bonne publicité suite au piratage de TV5 Monde survenu la même semaine. Autre fait d’actualité, le site GitHub a subi une attaque de déni de service fin mars, le rendant partiellement indisponible.
Quelles menaces pour mon application ?
Avant d’aller plus loin, il s’agit de savoir par où commencer pour protéger son application. Les intervenants proposaient deux méthodes développées par Microsoft.
- la méthode STRIDE pour identifier les menaces telles que l’usurpation d’identité, la divulgation d’informations, les élévations de privilèges, le déni de service, etc.
- la méthode DREAD pour établir un classement par priorité des vulnérabilités d’une application lors d’un audit. On catégorise ainsi les menaces en fonction des impacts et des risques.
Ce recensement des menaces permet de montrer au management les réels problèmes et de proposer les solutions adéquates.
Le module Spring Security
Le générateur JHipster est basé sur le framework Spring Boot, lui-même basé sur le module Spring Security. Ce module fournit un ensemble de fonctionnalités pour sécuriser les applications web Java. Il s’agit d’une solution fiable, éprouvée, et très largement utilisée, évitant ainsi de devoir réinventer la roue.
- la gestion des authentifications avec différents méthodes : OAuth1, OAuth2, SAML, Kerberos
- la gestion des autorisations/rôles
- une sécurité par défaut des entêtes HTTP : X-Frame, XSS, HSTS
- une protection contre les attaques CSRF
- possibilité d’auditer les accès.
Intranet
Le développeur doit partir du constat que, dès qu’il y a du réseau, il y a des risques. Contrairement aux idées reçues, un pare-feu ne sert pas à faire de la sécurité. Il réalise de la qualité réseau en arrêtant des paquets et en bloquant des ports pour arrêter le trafic inutile. Cependant, le port de notre application reste ouvert et donc potentiellement exploitable par des personnes mal intentionnées.
Pour réaliser du filtrage applicatif, il nous reste les répartisseurs de charge (load-balancer) en place pour nos applications, les DevOps ont accès la plupart du temps à ces composants. Les serveurs Apache, Nginx ou HAProxy peuvent analyser le contenu des messages du protocole. Un pirate a très peu de marge pour hacker un produit grand public.
Sécurisation de nos données
La divulgation d’informations est l’une des attaques les plus néfastes pour l’image d’une société, le piratage du Playstation Network en est un bon exemple. Il faut impérativement gérer les données confidentielles (nom, prénom, etc.) mais aussi limiter l’accès de certaines (salaires, données médicales) à des groupes restreints. Le moyen le plus sûr et efficace est de chiffrer ces données.
Chiffrer le front
L’utilisation du protocole HTTPS & SSL est une bonne solution, mais il faut prendre quelques précautions. Les clés de chiffrement doivent être longues et protégées, restreindre leur accès à un groupe de personnes de confiance pour éviter qu’elles soient subtilisées. Pensez également à choisir un algorithme de chiffrement suffisamment sécurisé.
Il est impensable d’effectuer une authentification sans utiliser une connexion sécurisée. On peut imposer avec Spring Security l’utilisation du HTTPS sur certaines URLs, par exemple pour l’authentification d’un utilisateur.
Chiffrer le back
Mongo fournit des fonctionnalités d’authentification et d’audit pour sécuriser les accès. Utilisez une connexion SSL entre Mongo et le serveur d’applications, votre réseau n’est pas à l’abri d’une attaque.
Pour le stockage, il est préférable d’effectuer le chiffrement des données au niveau de l’applicatif. On a une granularité fine, le chiffrement est appliqué sur les données confidentielles et pas à l’ensemble de notre espace de stockage.
Authentification & Autorisation
JHipster utilise une authentification avec un identifiant/mot de passe comme la majorité des applications. Une problématique de ce type d’authentification est la gestion des secrets, 100 % des attaques en 2014 impliquant ainsi des mots de passe dérobés. Avec la multiplication des comptes, les utilisateurs sont tentés d’opter pour un mot de passe unique. Il y a aussi le cas où ils sont stockés sur des supports non sécurisés (fichier non chiffré, Post-it) pour s’en souvenir. Autre problème, les systèmes de récupération des mots de passe :Paris Hilton s’est fait piraté son compte chez T-Mobile parce que son secret était le nom de son chien.
François et Romain proposent d’être qu’un fournisseur de services. On identifie un fournisseur d’identité de confiance afin de s’y interfacer pour déléguer l’authentification. De nombreux fournisseurs intègrent une authentification forte (en deux étapes) par la saisie du mot de passe et d’un code d’activation obtenu sur un terminal vérifié et lié au compte. L’idée est de remplacer la page de login vers un lien pour « prouver l’identité auprès du fournisseur d’identité ».
Authentification avec un lien vers un fournisseur d’identité
Authentification auprès du fournisseur d’identité
Pour cela, il propose d’utiliser le protocole SAML (Security Assertion Markup Language) ; il s’agit d’un standard pour l’authentification unique (Single Sign-on) sur le web qui permet à un utilisateur de naviguer sur plusieurs sites en ne s’identifiant qu’une seule fois. Spring Security propose un support SAML 2.0. En combinaison avec SAML, Oauth v2 assure une gestion fine des droits et ainsi autorise l’accès à des données, à une API.
Une implémentation, basée sur JHipster, de ces techniques d’authentification et d’autorisation est disponible ici.
Intégration continue
Les outils pour la gestion de cycle de vie des logiciels ne sont pas épargnés, ils sont des vecteurs possibles d’intrusion dans vos systèmes.
- Gestionnaire de sources. Inspecter systématiquement chaque commit poussé et son auteur par une revue de code. Vous devez également gérer vos secrets, ne publiez pas des clés de chiffrement ou des mots de passe compromettant la sécurité du système.
- Intégration continue. Sécuriser l’accès à Jenkins par un système d’authentification et d’autorisation. SAML est une option possible. Il est important d’identifier les personnes à l’origine d’un build.
- Gestion des dépendances. Vérifier la provenance des dépendances, des outils tels que Maven ou NPM rapportent de nombreuses librairies. Tous ces composants proviennent d’Internet. Un repository d’entreprise permet de les filtrer et de vérifier les sommes de contrôle (checksum). Nexus peut être un repository.
Conclusion
Avant de débuter cette conférence, je m’attendais à un sujet sur la sécurisation d’une application JHipster. Finalement, cette discussion a été au-delà de ce simple aspect et je n’ai aucun regret sur mon choix. La sécurité, c’est à l’affaire de tous, à commencer par les développeurs. En tant que développeur, nous sommes une cible idéale pour les pirates, nous avons la responsabilité de protéger nos secrets et nos accès.
Aujourd’hui, les développeurs doivent penser à la sécurité. L’expérience utilisateur n’est pas un prétexte pour une mauvaise sécurité, l’authentification forte n’est plus un luxe. Aucune organisation n’est à l’abri d’une cyberattaque : chiffrez vos données confidentielles et sensibles. Soyez prêt à endurer une attaque, ne ménagez pas vos serveurs, les pirates ne les ménageront pas.
Les slides de la conférence : http://www.slidesearchengine.com/slide/devoxx-2015-barbus-et-barbares
