Qu’est-ce que le Top 10 de l’OWASP ?

Le Top 10 de l’OWASP, une norme de référence qui fournit un classement des dix risques les plus critiques en matière de sécurité des applications web, ainsi que des conseils de remédiation, aide les développeurs et les spécialistes de la sécurité à mieux comprendre le paysage des menaces et à s’y retrouver. L’objectif ultime de la fondation Open Web Application Security Project (OWASP) est de contribuer à favoriser une culture du développement de logiciel sécurisé. Pour les développeurs et les administrateurs d’applications web, le Top 10 de l’OWASP constitue une référence fondamentale importante en matière de sécurité. Il fournit une base à partir de laquelle créer des applications web plus sécurisées

Qu’est-ce que l’Open Web Application Security Project (OWASP) ?

Le Open Web Application Security Project (OWASP), alias Open Web Application Security Project (OWASP) est une organisation à but non lucratif dont l’objectif est d’améliorer la sécurité des logiciels. Open Web Application Security Project (OWASP), en plus de fournir de l’éducation et des formations, propose une variété d’outils infosec utiles, tels que :

Zed Attack Proxy (ZAP)– Un outil open source populaire de test dynamique de la sécurité des applications (DAST) pour les analyses de vulnérabilités et les tests d’intrusion.
Dependency-Check– Un outil d’analyse de la composition logicielle (SCA) qui aide à la détection des vulnérabilités dans les dépendances.
Dependency-Track– Une plateforme d’analyse des composants de la chaîne d’approvisionnement conçue pour s’intégrer dans des environnements CI/CD et identifier les risques associés aux composants open source et tiers sur la base d’une nomenclature logicielle (SBOM).

Quels sont les 10 principaux risques de l’Open Web Application Security Project (OWASP) ?

Le Top 10 de l’OWASP est une liste des dix risques de sécurité les plus critiques pour les applications web. Il est conçu pour être un document de sensibilisation destiné aux développeurs et aux professionnels de la sécurité. Comme les menaces auxquelles sont confrontées les applications web, la liste elle-même change de temps à autre. Par exemple, la liste de 2013 a été mise à jour en 2017, et Open Web Application Security Project (OWASP) a collecté des données de mars à mai 2020 pour la mise à jour suivante.

Alors, quels risques composent le Top 10 de l’OWASP aujourd’hui ? Les voici :

1. Injection

Les attaques par injection se produisent lorsque des données sont envoyées à un interpréteur à l’aide d’un champ de saisie (par exemple, un formulaire ou une connexion) dans une application web. L’une des formes d’injection les plus courantes est l’injection SQL. Un exemple classique d’attaque par injection SQL peut être le suivant :

Une invite de connexion ne valide ni n’assainit correctement les entrées de nom d’utilisateur
Une base de données stocke les noms d’utilisateur et les mots de passe en texte brut (ne faites pas cela !) et manque de contrôle tels que SQL LIMIT
Normalement, l’invite de connexion de l’application web exécute une instruction SQL comme

SELECT * FROM utilisateur WHERE name = 'someuser' AND password = 'passwd'

Un utilisateur malveillant saisit le nom d’utilisateur « user OR 1 = 1 » et n’importe quel mot de passe.
L’instruction SQL devient

SELECT * FROM Users WHERE name = 'user' OR 1 = 1 --' AND password = 'passwd'

L’utilisateur malveillant accède au contenu protégé par mot de passe

Bien que de nombreuses applications empêchent aujourd’hui ce cas simple, il est important de se rappeler que toute zone d’une application web qui accepte des paramètres d’entrée peut faire l’objet d’une attaque par injection.

2. Défaillance de l’authentification

Une authentification défaillante désigne la mise en œuvre non sécurisée des méthodes d’authentification et de la gestion des sessions. Voici quelques signes d’une authentification défaillante :

Autoriser les attaques par force brute
Autoriser des mots de passe faibles comme « password »
Stockage de mots de passe en clair ou de mots de passe hachés avec une fonction de hachage faible ou compromise
Gestion inadéquate, rotation, et invalidation des ID de session et des jeton d’authentification

Pour limiter le risque qu’une faille divulgue des identifiants, lorsqu’un utilisateur crée un mot de passe, celui-ci doit être salé et haché avant d’être stocké. Le stockage des mots de passe en clair est l’exemple type du non-respect de cette bonne pratique, et même des géants du cloud public comme Google ont commis cette erreur.

De plus, l’authentification multifacteur (MFA), et la limitation du débit peuvent aider à résoudre certains des problèmes associés à une authentification défaillante, comme la vulnérabilité aux attaques par force brute.

3. Exposition de données sensibles

Cette vaste catégorie couvre l’exposition non autorisée de données sensibles au repos ou en transit. Souvent, les API ne chiffrent pas et ne transmettent pas correctement des données sensibles comme les mots de passe, les numéros de compte, les données de santé et d’autres informations personnelles identifiables (PII), ce qui entraîne un risque de compromission.

Une attaque Basic de l’homme du milieu (MITM) utilisant le SSL stripping nous fournit un exemple de la manière dont des faille de données sensibles peuvent se produire :

Un hacker compromet un point d’accès WiFi
L’utilisateur se connecte au point d’accès compromis
L’utilisateur tente de se connecter à https://someinsecuresite.net
Le hacker utilise un proxy pour transférer la requête de l’utilisateur au serveur via HTTPS
Le hacker supprime le chiffrement et renvoie des réponses à l’utilisateur via HTTP

Le hacker voit maintenant tout ce que l’utilisateur envoie à someinsecuresite.net en texte brut. Le serveur web somesecuresite.net n’a aucune idée que le trafic est compromis, car les requêtes reçues depuis le serveur du hacker utilisent HTTPS. L’utilisateur n’est pas conscient de l’attaque, car il semble que les réponses proviennent directement de someinsecuresite.net.

L’application de HTTP Strict Transport Security (HSTS) à toutes les pages, en particulier à celles qui traitent des données sensibles, est un moyen de réduire le risque d’exposition des données sensibles. De même, éviter l’utilisation d’un chiffrement faible comme SSL v3.0 ou TLS 1.0 contribue à renforcer la sécurité de vos utilisateurs. De plus, un chiffrement fort des données au repos peut atténuer les fuites d’information personnelle identifiable dans le cas où une base de données serait compromise.

4. Entités externes XML (XXE)

Le langage de balisage extensible (XML) est une structure de données courante, et de nombreuses applications web peuvent analyser des entrées XML. Une attaque XXE est liée à la manière dont cette analyse se produit. Un hacker envoie des données XML qui pointent vers une entité externe.

Un analyseur syntaxique XML vulnérable enverra alors des réponses à l’entité externe, exposant potentiellement des données sensibles. Par exemple, supposons qu’un hacker veuille accéder à /path/to/super/secret/file.txt sur un serveur web doté d’un analyseur syntaxique XML vulnérable. L’attaque pourrait ressembler à ceci :

Un hacker envoie une requête qui inclut ce XML
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE eggs[ <!ENTITY weakparser SYSTEM "file:///path/to/super/secret/file.txt"> ]> <movies><filmId>&weakparser;</filmId></movies>

2. Le serveur répond avec une erreur et le contenu de /path/to/super/secret/file.txt

5. Contrôle d’accès défaillant

Alors que le numéro deux du Top 10 de l’OWASP traite de l’authentification, le numéro 5 concerne ce qui se passe ensuite. Le contrôle d’accès fait référence aux limites associées à un ensemble donné de privilèges utilisateur.

Voici quelques exemples spécifiques de contrôle d’accès défaillant mentionnés par Open Web Application Security Project (OWASP) :

Utilisation d’une URL modifiée pour contourner les contrôles d’accès. Par exemple, si userA peut accéder aux informations du compte de userB simplement en remplaçant un lien de net/myapp/myaccount?user=userA
par someinsecuresite.net/myapp/myaccount?user=userB
Élévation de privilèges. Par exemple, une vulnérabilité ou une mauvaise configuration qui permet à un utilisateur d’effectuer des actions d’administrateur.
Accès non authentifié à des pages privilégiées. Par exemple, si un utilisateur non authentifié peut accéder à
net/myapp/super-secret-admin-page
et consulter des informations privilégiées qui nécessitent normalement une authentification.
Manipulation des métadonnées. Les exemples incluent la relecture ou la manipulation de jeton de contrôle d’accès ou de cookies, ainsi que l’utilisation abusive de l’invalidation de JSON Web Token.
Mauvaise configuration de CORS (Cross-Origin Resource Sharing). Un exemple courant de mauvaise configuration de CORS consiste à autoriser des requête provenant de « localhost » à interagir avec des application web de production.

6. Mauvaise configuration de sécurité

L’Open Web Application Security Project (OWASP) indique que la mauvaise configuration de la sécurité est le problème le plus courant de sa liste. Par défaut, de nombreuses formules sont livrées avec des paramètres non sécurisés, et les développeurs web ainsi que les administrateurs doivent les renforcer. De plus, la modification des configurations pour faire fonctionner une fonction spécifique peut entraîner une faille de sécurité involontaire.

Par exemple, autorise l’accès à un panneau d’administration avec un mot de passe par défaut ; les identifiants doivent être modifiés avant le déploiement en production. De même, les services et ports inutiles doivent être désactivés ou bloqués.

Le principal enseignement à retenir de cette entrée du Top 10 de l’OWASP est : assurez-vous de configurer de manière sécurisée les composants de votre application ET d’appliquer avec rigueur les correctifs de sécurité et les mises à niveau.

7. Scripts intersites (XSS)

Scripts intersites, également appelés Le XSS est un problème de sécurité courant auquel les applications web sont confrontées. Les attaque XSS injectent des scripts côté client dans le contenu web. Ils peuvent permettre à des hackers de voler des données, de détourner la session d’un utilisateur, ou d’afficher du contenu modifié sur une page web. Il existe plusieurs types d’attaques XSS, notamment :

XSS réfléchi – Cette forme simple d’attaque XSS est également connue sous le nom d’attaque XSS non persistante. Il utilise généralement une URL malveillante pointant vers un site légitime. Dans l’attaque, l’URL inclut des caractères spéciaux (par ex. caractères de contrôle HTML) que les pages vulnérables exécutent ensuite.
XSS stocké – Ces attaques sont également appelées XSS stocké. Dans le cas d’un XSS stocké, les données malveillantes fournies par un hacker sont enregistrées côté serveur. Le résultat est que le contenu compromis s’affiche pour tous les utilisateurs qui visitent la page.
Cross-site scripting (XSS) basé sur le Document Object Model (DOM) – Les attaques XSS basées sur le DOM sont uniques en ce sens que l’exploit ne touche généralement jamais le serveur. Du code front-end comme JavaScript est exploité pour exécuter des scripts malveillants.

8. Désérialisation non sécurisée

La sérialisation est le processus utilisé pour convertir des objets de données en un format spécifique à des fins telles que le streaming ou le stockage de données. Les données sérialisées peuvent être binaires ou en texte (comme JSON ou XML). La désérialisation est le processus qui inverse la sérialisation et reconvertit les données sérialisées en un objet de données.

Le processus de sérialisation/désérialisation peut devenir problématique lorsque des sources non fiables de données sérialisées entrent en jeu. Un hacker peut inclure des Opérations spécifiques dans les données sérialisées, et si l’attaque réussit, le serveur les exécutera pendant le processus de désérialisation. Cela signifie que la désérialisation non sécurisée peut être utilisée pour des attaques allant du déni de service distribué à l’élévation de privilèges.

Open Web Application Security Project (OWASP) fournit un bon exemple de désérialisation non sécurisée en utilisant comme exemple une application de forum vulnérable basée sur PHP. Supposons que l’application utilise un super cookie qui stocke un ID utilisateur, le rôle de l’utilisateur et les informations de hachage du mot de passe.
Un hacker pourrait modifier le cookie pour s’accorder des privilèges élevés, comme ceci :

Avant :

a:1:{s:1:"MalicousUser";i:1;s:2:"guest"; i:1;s:1:" fe7pmk43i1wstgqvsyask27g44yxn7qhl6zgkr7ivho1e6lv903xc9sbiq4b6mtx";}

Après :

a:1:{s:1:"SuperAdmin";i:1;s:2:"admin"; i:1;s:1:" fe7pmk43i1wstgqvsyask27g44yxn7qhl6zgkr7ivho1e6lv903xc9sbiq4b6mtx";}

9. Utilisation de composants ayant des vulnérabilités connues

Ce risque est exactement ce que son nom suggère : l’utilisation de composants vulnérables au sein d’une application web. Les applications web modernes dépendent de divers framework, bibliothèque, et module. Si l’un de ces composants sous-jacents présente des vulnérabilités de sécurité, l’ensemble de l’application peut être mis en danger. Comme pour le numéro six du Top 10 de l’OWASP, l’application de correctifs et de mises à niveau de sécurité peut grandement aider ici.

10. Carences des systèmes de contrôle et de journalisation

La détection rapide des menaces potentielles ou des failles confirmées constitue une part importante de la prévention ou de l’atténuation des dommages. L’activité malveillante présente souvent un schéma unique, et une surveillance efficace peut aider à la détecter rapidement. Dans de nombreux cas, les failles non détectées entraînent des dommages plus étendus, c’est pourquoi ce risque figure dans la liste. En fait, selon Open Web Application Security Project (OWASP), la plupart des études suggèrent que le temps nécessaire pour détecter une faille de données dépasse 200 jours.

Voici quelques exemples courants de journalisation et de surveillance insuffisantes :

Ne pas journaliser les événements à forte valeur, comme les connexions et les échecs de connexion
Aucune messagerie, ni aucun message d’erreur ambigu, ni aucun message de Log pour les événements de niveau avertissement ou supérieur
Stockage des Log uniquement en local sur le serveur
Les analyses de sécurité ne déclenchent pas de notifications ni d’Alertes
Aucune alerte en temps réel en cas d’attaque

Comment un WAF peut aider à traiter le Top 10 de l’OWASP

Il n’existe pas de solution miracle unique pour protéger votre application web contre les menaces du Top 10 de l’OWASP. Vous devrez vous assurer que la sécurité est prise en compte dans le code, dans la configuration de l’infrastructure, et dans les composants tiers que vous utilisez.

Cela dit, un pare-feu d'application web peut grandement simplifier la sécurisation de votre application web. La définition de l’Open Web Application Security Project (OWASP) d’un WAF met en avant les cas d’utilisation courants pour atténuer des attaques comme les XSS et les injections SQL.

Alors, comment exactement un WAF peut-il vous aider dans ces cas ? Les WAF correctement configurés peuvent détecter et bloquer des requêtes potentiellement malveillantes. En utilisant une combinaison de détections par défaut et de fonctionnalités personnalisables dans des solutions comme le Next-Gen WAF de Fastly, et en tirant parti des capacités de notre plateforme Edge Cloud, vous pouvez bénéficier d’une solide couverture du Top 10 de l’OWASP.

Pour des conseils plus détaillés et des exemples concrets de résolution des menaces de l’Open Web Application Security Project (OWASP) avec Fastly, vous pouvez consulter notre livre blanc.