Secure Software Development Life Cycle (SSDLC)

Le cycle de de vie du développement d’un application est l’ensemble des étapes de réalisation d’un logiciel dans le but de construire un produit de qualité.

L’intégration de la sécurité dans le SDLC intervient à chaque étape de celui-ci et se matérialise de plusieurs manières (threat modeling, review, SAST, DAST, etc.).

Ci-dessous, une liste non-exhaustive d’actions à mener au sein du SDLC pour délivrer une application sécurisée.

Ma présentation sur SlideShare : Secure Software Development Life Cycle (SSDLC)

Surveiller vos dépendances avec Dependency Check de l'OWASP

Selon le Gartner, dans une application, 80% du code est fourni par des dépendances (spring, ORM, parsing de XML/JSON, etc.). Sur 95% des applications qui contiennent des dépendances opensource, 65% contiennent des dépendances vulnérables.

Malheureusement, lorsqu’une dépendance est installée pour un besoin spécifique, le suivi est rarement fait pour se tenir à jour des nouvelles versions et encore moins des vulnérabilités qui pouvant l’affecter.

Dependency Check

L’OWASP propose un outil nommé Dependency Check permettant de lister et vérifier automatiquement pour toutes les dépendances d’une application si une CVE (Common Vulnerabilities and Exposures) a été publiée pour la version utilisée. La base de données utilisée par Dependency Check est le NVD Data Feeds proposée par le NIST.

Scanner les vulnérabilités d'un site web avec Arachni

Arachni est un scanneur de vulnérabilités web écrit en Ruby (cross-plateforme) par Tasos Laskos et permettant d’automatiser la détection d’un grand nombre de failles (XSS, SQL Injection, Local File Injection, Remote File Injection, etc.). Il est disponible sous la forme d’une interface web, une application console et une API REST.

Types de scans

Arachni permet de faire des scans actifs ou passifs.

Scans actifs

Ils testent la présence de failles sur les pages web visitées, par exemple :

Principe et implémentation de HSTS (HTTP Strict Transport Security)

HTTPS est devenu quasiment obligatoire sur tous les sites web et particulièrement sur ceux contenant des formulaires. Même si ce n’est pour le moment qu’une indication non bloquante, Firefox émet une erreur lors de la visite d’une page non sécurisée contenant des formulaires (en savoir plus).

Pour rappel, la mise en place du protocole HTTPS est maintenant facilitée par l’initiative Let’s Encrypt.

Problématique

Traditionnellement, sur un site web implémentant HTTPS, un utilisateur qui souhaite accéder à la version HTTP est redirigé via une HTTP 301 sur la version HTTPS :

Se protéger des failles XSS avec les headers CSP (Content Security Policy)

Les failles XSS (Cross-Site Scripting), étant classées en troisième position du dernier TOP 10 de l’OWASP, sont une porte d’entrée dans les systèmes d’information (scan de ports, exploits, etc.) et une menace pour les utilisateurs (vol d’information d’identifications).  Les traditionnelles contre mesures mises en place sont le filtrage des données entrantes sur le serveur (input filtering) et l’encodage des données sortantes (output encoding) afin d’éviter l’exécution de scripts malveillants sur les postes clients.