Aller au contenu

Le Guide de survie de OWASP 2017 (pour nos pipelines de CI/CD)

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.

OWASP (Open Web Application Security Project)

Le projet OWASP est :

  • un projet à but non lucratif, il a pour vocation de promouvoir les bonnes pratiques pour obtenir un monde plus sécurisé
  • agnostique à la technologie (PHP, .net, Java, …) et s’intéresse à toutes les stacks technologiques quelles qu’elles soient
  • contribué sans contrepartie par une communauté active d’expert en sécurité.

Top 10

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…

Voici les évolutions apportées par le millésime 2017

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 :

  • CSRF (Cross Site Request Forgery), ce type d’attaques est en baisse, les framework actuels disposant de protections à ces attaques.
  • Redirection et renvois non validés, ce point a été sorti pour laisser entrer les nouveaux sujets qui sont plus pertinents.

On notera l’arrivée de “Insecure deserialization” et de l’incroyable “Insufficient Logging & Monitoring” !

OWASP Top 10 Proactive Controls 2018

Il est toujours appréciable de se souvenir des quelques règles de bases à appliquer quand on développe une application.

  1. Define Security Requirements
  2. Leverage Security Frameworks and Libraries
  3. Secure Database Access
  4. Encode and Escape Data
  5. Validate All Inputs
  6. Implement Digital Identity
  7. Enforce Access Controls
  8. Protect Data Everywhere
  9. Implement Security Logging and Monitoring
  10. Handle All Errors and Exceptions

La SECU dans mon pipeline ou la sécurité en Continu

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

Analyse des dépendances ou l’analyse des dépendance en Continu

Coté Java

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.

Coté JavaScript

Le monde du javascript n’est pas en reste puisqu’OWASP a pensé à leurs pléthores des librairies open-source. Sera à votre disposition :

Coté des containers

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

Les licences ou la conformité en continu

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.

Analyse statique du code

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

Middlewares

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

Les serveurs Web

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.

  • HSTS : forcer le passage en https
  • Content-Security-Policy : maîtriser le chargement de sources (et mitiger les XSS /Cross site scripting) en limitant à des domaines / éviter également les scripts inline
  • X-Content-Security-Policy : complément à CSP sur des vieux navigateurs
  • X-XSS-Protection : complément à CSP sur des vieux navigateurs
  • X-Frame-Options : éviter le chargement par iframe
  • X-Content-Type-options : contrôler les types MIME
  • HPKP : stocker les clés de confiance pour détecter les éventuelles compromissions de certificats

Automatiser les Tests d’intrusions

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)”

Sécurité des applications Web les bons réflexes à avoir (E. Lenoir)

Conclusion

N’oubliez que les critères de choix de vos outils de test de sécurité sont :

  • supporter votre langage de programmation
  • les types de vulnérabilités qu’il peut détecter
  • comprendre les librairies que vous utilisez
  • monitorer (faux positif vs faux négatif)
  • l’intégration dans l’IDE de dev
  • la difficulté de paramétrage et d’utilisation
  • qu’il puisse être lancé continuellement et automatiquement !
  • et le coût de la license