· Blog de veille

La sécurité au travers de l’OWASP

La qualité d’une application web est intrinsèquement liée à la sécurité de cette dernière, c’est pourquoi nous avons décidé de vous faire une introduction sur l’OWASP et quelques concepts sur la sécurité applicative.

1. Définition

OWASP (Open Web Application Security Project) est un guide de sécurisation des applications web, c’est un « ouvrage » de référence des bonnes/mauvaises pratiques de développement, d’une base sérieuse en termes de statistiques, et d’un ensemble de ressources amenant à une base de réflexion sur la sécurité. Des outils sont aussi proposés pour effectuer un audit de sécurité.

2. Les projets de l’OWASP

De nombreux projets développés en interne sont proposés et disponibles librement sur le site officiel : https://www.owasp.org

Ces projets permettent aussi bien de faire de la veille, comme le TopTen d’OWASP qui liste annuellement les failles les plus couramment utilisées par des utilisateurs malveillants. Mais aussi des logiciels puissants, permettant de faire des audits de sécurité avancés sur n’importe quelle plateforme.

Sur le site d’OWASP est disponible un grand nombre d’articles détaillés sur des failles/vulnérabilités. Ces articles expliquent : le principe d’une faille, son impact, une ou plusieurs méthodes d’attaques, et un mécanisme de protection.

Le guide OWASP propose aussi des documents plus méthodologiques encadrant l’univers d’un RSSI (Responsable de la Sécurité des Systèmes d’Informations). Ces documents offrent une bonne pratique pour définir et qualifier les risques auxquels pourrait être confrontée une société, une application, etc… Afin de couvrir l’ensemble de l’environnement (humain et applicatif) pour ensuite manager les équipes sur les projets.

Voici une liste (non exhaustive) de projets populaires, ainsi qu’une description succincte :

– Top Ten : Liste des failles les plus couramment utilisées par des utilisateurs malintentionnés sur internet. Ce document est accompagné d’une qualification des menaces listées et d’une explication sur l’exploitation.

Cf : https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=2010_Translation_Efforts

Voici le Top Ten de l’année 2010 (vulnérabilités listées de la plus commune à la moins exploitée) :

  1. Injections
  2. Cross-Site Scripting (XSS) => Script corrompu à travers un site
  3. Broken Authentication and Session Management => Violation de Gestion d’Authentification et de Session
  4. Insecure Direct Object References => Références directes non sécurisées à un Objet
  5. Cross-Site Request Forgery (CSRF) => Falsification de requête inter-sites
  6. Security Misconfiguration => Mauvaise configuration de sécurité
  7. Insecure Cryptographic Storage => Stockage cryptographique non sécurisé
  8. Failure to Restrict URL Access => Manque de Restriction d’accès au niveau des URLs
  9. Insufficient Transport Layer Protection => Protection insuffisante de la couche Transport
  10. Unvalidated Redirects and Forwards => Redirections et Renvois non validés

Ce top 10 évolue dans le temps, certaines failles (comme les problèmes de sécurité dus à une mauvaise configuration) n’étaient plus dans le classement entre 2004 et 2010. Cet exemple montre qu’il y a de nombreux autres points à vérifier, qui ne sont pas listés dans ce classement. Même si vous pensez avoir sécurisé votre application web, vous pouvez déjà être vulnérable face à quelque chose auquel personne n’a jamais pensé auparavant. Certaines vulnérabilités dans les articles d’OWASP sont non-applicables au web, mais peuvent servir de base à une réflexion sur la sécurité et la création d’un référentiel de sécurité.

Il faut voir cette liste comme un référentiel du minimum à sécuriser.

– Webscarab : Un outil d’audit de sécurité. Il s’agit d’un proxy disposant d’une interface graphique qui, une fois relié à un navigateur, intercepte les requêtes/réponses HTTP entre le client et le serveur, ce qui permet de les analyser, de forger des requêtes soi-même, de tenter différentes injections, etc… Le proxy est intercalé entre le client et le serveur à la façon d’une attaque « Man in the middle ». Webscarab dispose de nombreux plugins permettant d’augmenter le nombre de fonctionnalités offert par l’outil (WebServices, Spider, XSS/CRLF, SessionID Analysis, etc…).

Cf : https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

Remarque: Par défaut il est livré avec uniquement l’intercepteur de requête, la version « self-contained » est livrée avec tous les plugins. Le gros défaut de cette solution est qu’elle n’est pas régulièrement mise à jour (dernière en date : 04 Mai 2007) et n’intègre pas les dernières vulnérabilités découvertes.

L’intérêt de cette solution : avoir un outil qui facilite un audit applicatif. Ce logiciel ne permettra pas d’avoir une application ayant une sécurité élevée s’il est utilisé seul. D’autres tests seront à faire pour accroitre la sécurité de votre application.

– Webgoat : Il s’agit cette fois d’une application web volontairement non sécurisée. Elle est livrée avec un tutoriel et des exercices pratiques. Une fois de plus, OWASP met en avant l’aspect pédagogique de ces solutions, ayant pour but d’instruire l’intéressé sur les différentes techniques d’exploitation de vulnérabilités. L’intérêt est de former le développeur à produire un code sûr.

Cf : https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

D’autres projets intéressants et utiles pour le milieu de l’entreprise existent, mais ils feront sûrement l’objet d’un prochain article plus détaillé.

3. Orienter les développements vers une démarche défensive

Chaque projet est différent et comporte un seuil de criticité propre à lui. C’est pourquoi il faut qualifier chaque risque associé à ce dernier.

Une méthode consiste à créer un tableau croisé entre les vecteurs d’attaques (XSS, CSRF, etc…) et les risques résultants de ces attaques (défiguration du site, corruption du contenu de la base de données, perte de données confidentielles, interruption totale/partielle de service, etc..).

Chaque projet devrait avoir son propre référentiel de sécurité (Base OWASP + Spécificités du projet + Risque acceptable ou non en fonction du projet).

Une fois les vecteurs d’attaques définis, on est en mesure de prioriser l’implémentation de correctifs de sécurité.

Conclusion

Le guide OWASP regorge d’informations utiles pour tout niveau de compétence. Le développeur non initié au domaine de la sécurité verra cet univers démystifié, l’expert y verra une base de connaissances sur laquelle il pourra se reposer. Les outils proposés sont efficaces même si certains ne sont pas assez maintenus ou accumulent un retard par rapport à d’autres solutions Open-source. L’OWASP reste toutefois un référentiel soutenu par le milieu professionnel et amène à une réflexion intellectuelle sur le domaine de la sécurité, auquel chaque développeur devrait être sensibilisé.