OWASP et son TOP 10 - Sécuriser ses applications WEB

OWASP et son TOP 10 - Sécuriser ses applications WEB

L'OWASP pour "Open Web Application Security Project" est une communauté en ligne travaillant sur la sécurité des applications Web.
La philosophie de l'OWASP est de fournir un contenu libre d'accès et ouvert à tous (licence CC-BY).
Le TOP 10 OWASP décrit les 10 risques principaux liés à la sécurité des applications WEB.
En mettant en oeuvre les bonnes pratiques permettant la lutte contre ces 10 risques, vos applications WEB seront parmi les plus sécurisées de l'internet (plus de 90% des attaques actuelles sont liées à l'exploitation de ces failles).
Aujourd'hui, la grande majorité des applications WEB sont vulnérables à au moins un des dix risques remonté par OWASP.

Logo Top 10 OWASP



Le Top 10 en synthèse

A1 - Injection
Empêcher une Injection exige de séparer les données non fiables des commandes et requêtes.

A2 - Violation de Gestion d’Authentification et de Session
Rendre accessible aux développeurs: Un ensemble unique de contrôles d'authentification et de gestion de sessions et, réaliser un effort particulier sur la prévention des failles XSS.

A3 - Cross-Site Scripting (XSS)
La protection contre XSS requiert une gestion des données non fiables séparée du contenu du navigateur actif (plus d'infos sur cet article du blog dédié aux failles XSS.).

A4 - Références directes non sécurisées à un objet
Afin d’éviter les références directes non sécurisées il convient de suivre une approche permettant de protéger chaque objet mis à disposition des utilisateurs (ex : nom de fichier, etc.).

A5 - Mauvaise configuration Sécurité
La recommandation principale est de mettre en place tous les points suivants :
1. Un processus de durcissement reproductible qui permet un déploiement rapide et facile d’un nouvel environnement correctement verrouillé. Dev, QA et Prod devraient être configurés identiquement(hors accès).
Ce processus devrait être automatisé pour minimiser les efforts de configuration d’un nouvel environnement.
2. Un processus d’information et de déploiement de nouvelles versions et de correctifs dans un temps voulu dans chaque environnement. Ceci inclut le code de librairies.
3. Une architecture solide qui apporte une séparation et sécurité entre les composants.
4. Utiliser les scans et les audits aident à la détection des futures mauvaises configurations ou absence de correctifs.

A6 - Exposition de données sensibles
1. Identifier les menaces contre lesquelles l’on souhaite se protéger (ex.: menace interne, utilisateurs externes) et s’assurer que les données sensibles sont chiffrées correctement lors de leur stockage et de leur transport...
2. Ne conserver que les données sensibles nécessaires. Les données que l’on ne possède pas ne peuvent être volées!
3. Choisir des algorithmes éprouvés et générer des clés robustes. S'assurer qu'une gestion des clés est en place. Privilégier des modules cryptographiques certifiés.
4. Stocker les mots de passe au moyen d’un algorithme adapté à cet usage, tel que bcrypt, PBKDF2, or scrypt.
5. Désactiver la mise en cache et l'attribut "autocomplete" dans les formulaires collectant des données sensibles.

A7 - Manque de contrôle d’accès au niveau fonctionnel
Votre application devrait utiliser un module de gestion des autorisations consistant, facilement analysable et appelé depuis les fonctionnalités métier. Ce type de protection est fréquemment fourni par des composants externes.

A8 - Falsification de requête intersite (CSRF)
La méthode standard de protection nécessite d’ajouter un jeton aléatoire à chaque requête HTTP. Ces jetons doivent, au minimum, être uniques par session utilisateur :
1. La meilleure option est d’inclure un jeton unique dans un champ caché. Ce jeton, envoyé dans le corps de la requête HTTP, et non inséré dans l’URL, sera ainsi potentiellement moins exposé.
2. Le jeton unique peut aussi être inclus directement dans l’URL, ou dans un paramètre de l’URL. Mais il risque d’être accessible à l’attaquant et ainsi d’être compromis.

A9 - Utilisation de composants avec des vulnérabilités connues
Une option est de ne pas utiliser des composants que vous n’avez pas vous même écrit. Mais cela n’est pas très réaliste. De nombreux projets de composants ne fournissent pas de correctifs de sécurité pour les anciennes versions.
A la place, le problème étant simplement corrigés dans la version suivante. De ce fait, effectuer une montée de version est critique.

A10 - Redirections et Renvois Non Validés
L’utilisation de manière sûre de renvois et de redirections peut être effectuée de différentes façons:
1. Eviter l’utilisation des redirections et des renvois.
2. En cas d’utilisation, ne pas utiliser de valeur de destination dans les paramètres utilisateur. Ceci est généralement réalisable.
3. Si une valeur de destination doit être spécifiée, vérifier que la valeur est valide et autorisée pour l’utilisateur.
Il est recommandé de ne pas utiliser d’URL dans les paramètres, mais plutôt une valeur abstraite qui sera traduite côté serveur par une URL cible. Les applications peuvent utiliser ESAPI afin de bénéficier de la fonction sendRedirect() permettant de s’assurer que les redirections soient sûres.
L’éradication de telles failles est extrêmement importante car elles sont principalement utilisées dans des attaques de phishing afin de gagner la confiance des utilisateurs.

Répartition des risques

Table criticite OWASP


Le tableau ci-dessus fourni par l'OWASP décrit de manière globale les risques de sécurité associés à chacun des 10 facteurs du top 10.
Pour faire simple, plus il y a de rouge sur une ligne, plus ce point mérite de retenir votre attention (soit les conséquences d'une attaque seraient risquées pour vous soit la mise en oeuvre d'une attaque est extrêmement simple).
Comme indiqué dans ce tableau, deux colonnes (Agents de Menace et Impacts Métier) sont laissées "vides". Idéalement, pour chacune de vos applications, vous devriez prendre le temps de remplir ces deux colonnes afin d'avoir une vision globale sur les risques et impacts d'une attaque sur votre nouvelle application WEB.


Sources OWASP

Le résumé du TOP 10 ICI [PDF 22 pages].

Tout sur le TOP10 ICI [SiteInternet].


Bon courage dans la mise en oeuvre de votre politique de sécurité et tout particulièrement dans l'implémentation du TOP 10 de l'OWASP !


Une question, un besoin ?

Nous sommes à votre écoute !