Le choix des méthodes agiles est désormais dans les moeurs de la plupart de nos clients. Les initiatives DevOps se multiplient également. Mais où en est on de la prise en compte de la sécurité de nos applications par les équipes ?
Lors de la conférence DEVOXX 2018, Erik Lenoir nous a partagé les bons réflexes à avoir en terme de sécurité pendant la phase de développement. Je vais vous en retranscrire l’essentiel.
Le projet OWASP est :
Le TOP 10 de l’OWASP est un projet visant à maintenir à jour la liste des 10 risques de sécurité et vulnérabilités les plus critiques affectant les applications Web. Le classement 2017 est disponible sur le site de l’OWASP (https://www.owasp.org/index.php/top10) sachant que le précédent datait de 2013 :-(
Ce classement a pour but d’informer sur l’existence de ces vulnérabilités et de fournir des guides simplifiés sur les bonnes pratiques pour s’en prémunir. Ces guides s’adressent aux développeurs, architectes, chef de projets, managers…
OWASP Top10 2017
Les risques liés à l’Injection (SQL, NoSQL, LDAP, code, système, …), la gestion de l’authentification et de la session sont et restent en tête du classement. Par contre, deux risques sortent de ce top 10 :
On notera l’arrivée de “Insecure deserialization” et de l’incroyable “Insufficient Logging & Monitoring” !
Il est toujours appréciable de se souvenir des quelques règles de bases à appliquer quand on développe une application.
Il n’est pas donné à tout le monde d’avoir une vision des risques dans son ensemble. Pour cela, il faudrait en avoir une entière compréhension… Par contre, La communauté OpenSource et des éditeurs vous mettent à disposition tout un panel d’outils pour vous défendre (ou du moins vous sensibiliser à la cyber-sécurité) ! Regardons quelques moyens de gérer la vulnérabilité des applications au travers leurs codes sources.
Une erreur classique est l’utilisation d’un composant dont les vulnérabilités sont connues
OWASP dependency check (plugin gradle et maven) : Il construit l’arbre de dépendances transitif et pour chaque dépendances, il consultera la liste des alertes de la NVD (national vulnerability database) afin de vous prévenir d’une quelconque vulnérabilité connue.
sources : https://github.com/jeremylong/DependencyCheck
Pour les plus consciencieux, vous pourrez casser votre build ! OWASP vous fournit également Dependency Track (https://dependencytrack.org/) un dashboard pour le suivi de vos analyses.
Le monde du javascript n’est pas en reste puisqu’OWASP a pensé à leurs pléthores des librairies open-source. Sera à votre disposition :
N’oublions pas les vulnérabilités des images des containers eux-mêmes. Il y a quelques produits très intéressants à regarder :
Il existe également des scripts de contrôle de la configuration de vos serveurs. Docker met à disposition Docker Bench Security, un script qui vérifie un bon nombre de bonnes pratiques autour du déploiement des containers Docker (https://github.com/docker/docker-bench-security).
DBS (https://www.blackducksoftware.com/) et XRAY (https://jfrog.com/xray/) pourront vous assurer que vous utilisez bien des librairies pour lesquelles vous avez le droit. On oublie souvent de vérifier le niveau et la qualité d’une librairie Open-Source.
Les éditeurs des analyseurs de code s’y sont mis aussi. SonarSource fourni des régles de sécurité contre des vulnérabilités (https://rules.sonarsource.com/java/type/Vulnerability). Pensez à les activer !
Coté javascript (enfin ECMA Script ou ES), on regardera également les linter de securité comme eslint-plugin-security (https://github.com/nodesecurity/eslint-plugin-security).
Activer l’authentification ! Son absence est l’une des plus banale erreur que l’on retrouve encore. Les équipes de MySQL lançaient jusqu’à il y a encore quelques années que la seule faille de sécurité connue pour leur SGBD était le couple d’identifiant par défaut (root et pas de mots de passe ;-) ).
Côté système, les experts vous préconiseront en premier lieu d’utiliser un chiffrement physique qui évitera le vol de données en les copiant physiquement ! La commision européenne vous mènera certainement vers un changement profond dans la manière de gérer les données personnelles et de les protéger, vous menant vers le chiffrement logique (ou par colonne).
Certains petits ajustements peuvent aussi vous permettre une avancée significative en matière de sécurité. Ces modifications sont minimes en termes de code et de configuration, mais elles requièrent une bonne analyse et une validation avant d’être implémentées. Il s’agit des headers HTTP.
OWASP fourni le project ZAP (Zed Attack Proxy https://www.zaproxy.org/), un outil gratuit de tests d’intrusion qui permet de détecter les vulnérabilités de vos applications web. Il a plusieurs modes d’opérations (passif/safe et actif). ZAP est très pratique par son coté “scriptable”, lequel viendra évidemment compléter votre pipeline de build ;)
Retrouver la vidéo originale : “Sécurité des applications Web les bons réflexes à avoir (E. Lenoir)”
N’oubliez que les critères de choix de vos outils de test de sécurité sont :
