OWASP Top 10: Les Menaces à Connaître

1. Introduction aux menaces OWASP

1.1 L'organisation OWASP

L'OWASP (Open Web Application Security Project) est une organisation à but non lucratif consacrée à l'amélioration de la sécurité des applications logicielles. Créée en 2001, elle est aujourd'hui largement reconnue par les professionnels de la sécurité informatique pour la qualité de ses guides de bonnes pratiques, de ses outils de test de sécurité et de ses formations¹.

Note : OWASP est constituée de volontaires de tous horizons qui travaillent ensemble pour produire des articles, méthodologies, documentations, outils et technologies gratuits et ouverts à tous.

OWASP est surtout connue pour son "OWASP Top 10" - une liste régulièrement mise à jour des dix menaces de sécurité les plus critiques pour les applications web ². Ce top 10 est un précieux outil de référence pour les professionnels du développement web et de la sécurité informatique.

¹ : https://www.owasp.org ² : https://owasp.org/www-project-top-ten/

1.2 Présentation générale des menaces

L'OWASP Top 10 n'est pas une liste exhaustive de toutes les menaces potentielles auxquelles une application web peut être confrontée. Il s'agit plutôt d'un condensé des vulnérabilités les plus courantes et les plus dangereuses. Les menaces sont classées en fonction de leur prévalence et de leur potentiel destructeur.

Selon l'OWASP, une application qui n'est pas protégée contre ces dix menaces présente un haut risque d'être compromise. Il est donc fortement recommandé pour toute organisation de prendre des mesures pour se protéger contre ces menaces[^3^].

Parmi les menaces les plus courantes, on peut citer :

• L'injection : où des données malicieuses sont insérées dans une requête afin d'obtenir un comportement non désiré de l'application
• La violation de gestion d'authentification : qui se produit lorsque les mécanismes d'authentification d'une application sont mal configurés ou insuffisamment robustes
• L'exposition de données sensibles : qui se produit lorsque des informations sensibles sont divulguées, intentionnellement ou non, à des acteurs non autorisés

Dans le reste de ce guide, nous examinerons en détail chacune de ces menaces et découvrirons comment s'en protéger.

[^3^] : https://owasp.org/www-pdf-archive/OWASP_Top_10-2017_%28en%29.pdf.pdf

Références

1. OWASP. (n.d.). OWASP. Retrieved October 14, 2021, from https://www.owasp.org

2. OWASP Top Ten. (n.d.). OWASP. Retrieved October 14, 2021, from https://owasp.org/www-project-top-ten/

3. OWASP Top 10 - 2017: The Ten Most Critical Web Application Security Risks. (2017). Retrieved from https://owasp.org/www-pdf-archive/OWASP_Top_10-2017_%28en%29.pdf.pdf

2. Menace N°1: Injection

L'injection est une menace grave qui se produit lorsque des données non fiables sont envoyées à un interpréteur. Elle occupe la première place des menaces identifiées par l'OWASP.

2.1 Comprendre l'injection

L'attaque par injection peut se présenter sous plusieurs formes, dont l'injection SQL, OS et LDAP. Les conséquences peuvent être désastreuses : accès non autorisé, perte de données, corruption de données, etc. L'épée de Damoclès réside dans l'interprétation des données malveillantes comme une commande légitime par l'interpréteur.

Pour donner un exemple clair d'injection SQL, considérez le code suivant:

1String query = "SELECT * FROM users WHERE username = '" + username + "'";

Un utilisateur malintentionné peut injecter une commande, par exemple, nothing'; DROP TABLE users; --. Cela se traduirait par une requête comme ceci:

1SELECT * FROM users WHERE username = 'nothing'; DROP TABLE users; --'

2.2 Prévenir et gérer les attaques d'injections

Pour se prémunir contre ces menaces, plusieurs mesures sont recommandées :

1. Utiliser un langage de programmation ou une librairie qui offre des requêtes paramétrées (également appelées préparées) pour séparer les données des commandes.

2. Utiliser des Web Application Firewall (WAF). Des outils comme ModSecurity, NAXSI ou Cloudflare peuvent offrir une couche de protection supplémentaire.

3. Sanitization des entrées : Cela signifie simplement s'assurer que les entrées sont « propres », en les passant par une fonction de sanitization qui élimine tout potentiel de code malveillant.

Important: Ne vous contentez pas de blacklister, car les hackers peuvent toujours trouver le moyen de contourner cela. Choisissez une approche de whitelist qui n'accepte que les entrées définies comme sûres.

4. OWASP offre également une liste d'évasion d'injection SQL pour se défendre contre les attaques d'injection.

5. Faire régulièrement des audits de sécurité : Il s’agit souvent de la dernière ligne de défense, car même si vous suivez toutes les bonnes pratiques, il est toujours possible que des erreurs passent inaperçues.

En conclusion, l'injection est une menace sérieuse, mais avec une bonne compréhension et une mise en place de bonnes pratiques, elle peut être efficacement contrée.

3. Menace N°2: Violation de gestion d'authentification

3.1 Comprendre la violation de gestion d'authentification

La Violation de Gestion d'Authentification, c'est lorsque l'attaquant parvient à contourner le processus d'identification, d'authentification ou de gestion de session. Cela peut être causé par une implémentation incorrecte sur ces processus ou par des défauts dans la conception du système. En conséquence, l'attaquant peut usurper l'identité d'autres utilisateurs, accéder à des informations sensibles ou effectuer des actions sans autorisation.

Note:

Il ne faut pas confondre avec le piratage de mot de passe, qui est une attaque contre un utilisateur spécifique. Ici le défi est plus sévère, c'est l'ensemble du système de gestion d'authentification qui est visé.

Voici deux exemples typiques de violation de gestion d'authentification :

1. Un site Web qui autorise l'utilisateur à rester connecté, mais qui enregistre mal cette information, permettant à un attaquant de copier les cookies et d'usurper l'identité de l'utilisateur.
2. Une application web qui ne gère pas correctement la fin des sessions, permettant à un attaquant d'utiliser une session terminée pour accéder au compte d'un utilisateur.

3.2 Mesures de protection contre cette menace

Pour se protéger contre la Violation de Gestion d'Authentification, il y a plusieurs précautions à adopter :

• Vérification d'identité: Utiliser des méthodes de vérification d'identité robustes. Il peut s'agir de l'authentification multi-facteurs, de la demande de renouvellement de mot de passe après une certaine période, ou de l'ajout de questions de sécurité.

• Gestion des sessions: Les sessions doivent être bien gérées. Chaque session doit avoir un identifiant unique et être fermée dès qu'elle n'est plus utilisée.

• Encryption: Les informations sensibles doivent toujours être chiffrées, en particulier lors de la transmission sur le réseau.

• Utilisation de librairies et cadres de confiance: Il est préférable de ne pas réinventer la roue et d'utiliser des librairies ou des cadres éprouvés pour la gestion des authentifications.

En outre, une analyse régulière de la sécurité de votre site est nécessaire pour détecter les éventuelles failles. Enfin, la sensibilisation des utilisateurs est également importante, car une bonne pratique de leur part peut grandement contribuer à la sécurité globale.

Pour plus d'informations sur cette menace, vous pouvez consulter le guide officiel de l'OWASP.

4. Menace N°3: Exposition de données sensibles

4.1 Qu'est-ce qu'une exposition de données sensibles ?

L'exposition des données sensibles survient lorsqu'un acteur non autorisé accède à des informations sensibles sur un site web ou une application. Les données sensibles peuvent inclure des informations personnelles identifiables (PII), des données financières, des détails de santé, des numéros d'identification nationaux et d'autres types de données qui nécessitent une protection.

Selon l'OWASP, l'exposition de données sensibles est la troisième menace la plus dangereuse pour les applications web en 2021. Elle peut résulter d'une panoplie de vulnérabilités, notamment un chiffrement incorrect, une mauvaise configuration ou un défaut de mise en œuvre de contrôles d'accès.

4.2 Comment se protéger de l'exposition des données sensibles ?

Protéger votre application contre l'exposition de données sensibles nécessite plusieurs étapes. Voici quelques-unes des recommandations de l'OWASP :

Identifiez et classez les données sensibles

Important: La première étape pour protéger les données sensibles est de les identifier et de les classer en fonction de leur niveau de sensibilité.

Appliquez le principe du moindre privilège

Il s’agit de n’accorder aux utilisateurs et aux systèmes que les privilèges nécessaires pour effectuer leur travail. Tout accès supplémentaire devrait être interdit par défaut.

Mettez en œuvre un chiffrement solide

Toutes les données sensibles stockées dans des bases de données, des fichiers ou des communications réseau doivent être chiffrées. Les standards de chiffrement varient en fonction du type de données mais, en règle générale, les techniques de chiffrement symétrique sont recommandées pour le stockage de grandes quantités de données et les techniques de chiffrement asymétrique pour les communications sécurisées en ligne.

Testez régulièrement

Faites régulièrement des tests de pénétration et des vérifications de sécurité pour s'assurer que vos mesures de protection sont efficaces.

Pour une protection supplémentaire, considérez la mise en œuvre de la pseudonymisation et de l'anonymisation des données personnelles. Ces techniques peuvent aider à réduire les risques liés à l'exposition de données sensibles.

À savoir: OWASP offre un guide détaillé sur les meilleures pratiques pour sécuriser les données sensibles. C'est une ressource inestimable en matière de protection contre l'exposition de données sensibles.

En résumé, l'exposition de données sensibles est une menace sérieuse à la sécurité de toute application web. La mise en œuvre de méthodes de protection efficaces et régulièrement testées est essentielle pour assurer la sécurité des données de vos utilisateurs.

Rappelez-vous qu'il est beaucoup plus coûteux de réagir à une violation de données que de mettre en place des mesures de protection appropriées dès le départ.

5. Menace N°4: XML External Entity (XXE)

5.1 Comprendre la menace XXE

Une attaque XXE exploite une vulnérabilité dans l'analyse d'un document XML. Les applications qui analysent le XML peuvent, en effet, traiter les entités de type DOCTYPE définies dans le document. Une entité peut être interne (sa valeur est définie dans le DOCTYPE) ou externe (sa valeur est un URI qui est résolu et remplacé par l'analyseur XML).

Exemple simple en XML:

1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE foo [
3<!ELEMENT foo ANY >
4<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

Dans cet exemple, un attaquant pourrait accéder aux données sensibles, d'une machine distante, spécifiquement le fichier /etc/passwd ¹. C'est une intrusion décrite comme une atteinte à la confidentialité des données.

5.2 Mesures de protection contre XXE

Première défense: Désactivation de l'analyse DTD

La plupart des attaques XXE peuvent être empêchées en désactivant l'analyse DTD dans le parseur XML que vous utilisez. Voici un exemple de configuration avec Java et l'API SAX:

1SAXParserFactory spf = SAXParserFactory.newInstance();
2spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

Deuxième défense: Utilisation de Bibliothèques XML sécurisées

L'autre option est d'utiliser des bibliothèques XML sécurisées comme defusedxml pour Python².

De plus, il est aussi recommandé de mettre à jour régulièrement vos bibliothèques et dépendances pour bénéficier de leurs derniers correctifs de sécurité.

Note: Il convient de réaliser des tests de pénétration sur vos applications pour vous assurer que vous n'êtes pas vulnérables aux attaques XXE. Des outils comme OWASP Zap peuvent aider à identifier ces vulnérabilités.

6. Menace N°5: Violation de contrôle d'accès

6.1 Comprendre la Violation de contrôle d'accès

La violation de contrôle d'accès est une menace particulièrement redoutée. Elle se produit lorsqu'une personne non autorisée parvient à accéder à certaines fonctionnalités ou données. Cela peut se produire lorsque les contrôles d'accès ne sont pas correctement mis en place ou lorsqu'un utilisateur malveillant parvient à contourner ces contrôles.

La violation de contrôle d'accès peut conduire à des conséquences désastreuses, notamment à l'accès non autorisé à l'information, à la modification ou à la suppression de données, et elle peut compromettre la confidentialité, l'intégrité et la disponibilité d'un système.

1// Exemple de contrôle d'accès insuffisant
2router.get('/api/admin/data', function(req, res) {
3  // Pas de vérification des droits de l'utilisateur
4  return res.json(privateData);
5});

6.2 Les recommandations de l'OWASP pour cette menace

La violation de contrôle d'accès est une menace qui peut être efficacement contrôlée par la mise en œuvre d'un certain nombre de mesures de protection. Voici les recommandations de l'OWASP:

• Mettre en œuvre une politique de contrôle d'accès basée sur le principe du moindre privilège. Chaque utilisateur ne doit avoir que les droits dont il a réellement besoin pour son travail.

• Utiliser des contrôles d'accès au niveau du serveur et du client. Il est crucial de se rappeler que les contrôles côté client peuvent être facilement contournés par un attaquant.

• Eviter l'utilisation d'URL directes pour accéder à des ressources spécifiques.

• Vérifier l'accès à chaque requête de l'utilisateur à une méthode de l'API ou à un point de terminaison de l'API.

• Vérifier les autorisations chaque fois que les privilégies d'un utilisateur changent.

• Enfin, tester régulièrement les contrôles d'accès.

1# Exemple de contrôle d'accès
2@app.route('/api/admin/data')
3@login_required
4@roles_required('admin')  # Use of the @roles_required decorator to restrict access
5def api_admin_data():
6    return jsonify(privateData)

7. Menace N°6: Mauvaise configuration de la sécurité

7.1 Qu'est-ce que la mauvaise configuration de la sécurité ?

La mauvaise configuration de la sécurité, quatrième menace principale du Top 10 de l'OWASP, regroupe toutes les erreurs de paramétrage qui pourraient rendre votre application vulnérable aux attaques. Un serveur web incorrectement sécurisé, des comptes par défaut ou encore l'exposition d'informations sensibles peuvent entrer dans cette catégorie.

Une mauvaise configuration peut résulter de plusieurs facteurs tels que:

• Le manque de compréhension des paramètres de sécurité
• L'utilisation de valeurs par défaut pour les configurations
• L'absence de sécurisation des fichiers de configuration
• La non mise à jour des logiciels et des systèmes opérationnels

Attention, dans le monde du web, une mauvaise configuration de la sécurité peut rapidement tourner au désastre.

7.2 Les bonnes pratiques pour une bonne configuration de la sécurité

Pour éviter les conséquences désastreuses, voici quelques bonnes pratiques pour une meilleure configuration de la sécurité.

• Maintenir une politique de sécurité mise à jour : Cela implique d'avoir une vision précise des normes, des protocoles et des processus à respecter dans votre organisation.

• Conduire régulièrement des audits de sécurité : Aide à la détection précoce des vulnérabilités potentielles.

• Mettre en place un processus de gestion des patchs et des mises à jour : Garantit que vous êtes protégé contre les dernières menaces.

• Utiliser des outils d'analyse statique de code source : Ces outils peuvent détecter rapidement les problèmes dans votre code avant qu'ils ne deviennent un problème en production.

S'assurer que le système de fichiers est sécurisé est également essentiel. Cela peut être réalisé en s'assurant que les permissions sont correctement attribuées, que les fichiers sensibles sont correctement protégés et que l'accès à l'information est restreint comme il se doit.

Remarque importante, n'oubliez jamais que le principe de base en matière de sécurité est la prévention. Réduire les risques doit toujours être votre priorité numéro un.

En conclusion, une stratégie de sécurité efficace est un mix de plusieurs disciplines. Cela va de la sensibilisation de vos équipes, à la mise en place d'outils adéquats, en passant par la conduite régulière d'audits de sécurité. Prenez toujours au sérieux la menace que représente une mauvaise configuration de la sécurité.

8. Menace N°7: Cross Site Scripting (XSS)

8.1 Comprendre les attaques XSS

Cross Site Scripting, plus communément appelé XSS, est une menace de sécurité web bien connue. Elle permet à un attaquant d'injecter du code malveillant (généralement des scripts) dans des pages web vues par d'autres utilisateurs. Le but ? Accéder à des informations sensibles et effectuer des actions en leur nom.

C'est une menace très courante pour plusieurs raisons. D'une part, elle est relativement facile à mettre en œuvre. D'autre part, elle peut causer des dommages considérables. De surcroît, elle vise les utilisateurs finaux, ce qui la rend plus imprévisible et difficile à contrer.

Selon une étude de Sucuri, plus de 80% des failles de sécurité sur le web sont attribuables à XSS.

Il existe principalement trois types de XSS: le XSS stocké, le XSS reflété et le XSS DOM. Chacun a ses propres caractéristiques et méthodes d'attaque.

8.2 Les conseils de l'OWASP pour contrer XSS

La mission de l'OWASP est de rendre le web plus sûr. Il recommande plusieurs stratégies pour contrer les attaques XSS.

1. Validation de l’entrée: Assurez-vous que toutes les entrées de l'utilisateur sont validées, filtrées ou désinfectées. L'idée est d'empêcher l'injection de contenus malveillants.

2. Désactivation de scripts: Utilisez des en-têtes HTTP pour désactiver les scripts pour certains types de contenu.

3. Échappement des données de sortie: Assurez-vous que les données dynamiques sont correctement échappées avant qu'elles ne soient présentées à l'utilisateur.

4. Mise à jour des logiciels: Assurez-vous que toutes les applications et tous les systèmes d'exploitation sont à jour et dépourvus de vulnérabilités connues.

5. Utilisation des entêtes de sécurité répondant à la Politique de Sécurité de Contenu (Content Security Policy, CSP): C'est une solution puissante pour prévenir le XSS, CSP permet de contrôler les ressources auxquelles a accès votre document, empêchant l'exécution de scripts non autorisés.

Remarque : Le problème du XSS n’est pas vraiment dans les scripts en soi, mais dans le fait qu'ils sont exécutés de manière indésirable. Alors que la plupart des contenus web modernes reposent sur l'exécution de scripts pour la création d'interactivités riches. Par conséquent, le but n'est pas d'éliminer tous les scripts, mais de contrôler leur exécution pour une expérience utilisateur sûre et sans faille.

9. Menace N°8: Insecure Deserialization

9.1 Qu'est-ce que l'Insecure Deserialization ?

La désérialisation non sécurisée, ou Insecure Deserialization, est une menace réelle en développement web. Elle survient lorsqu'une application désérialise des données sans prendre les précautions nécessaires, ouvrant ainsi la voie à des attaques malveillantes.

Pour comprendre ce problème, il faut d'abord comprendre la sérialisation. C'est le processus par lequel on transforme un objet en format qui peut être transporté ou stocké, souvent une chaîne de caractères. La désérialisation est le processus inverse.

1# Un exemple simple de sérialisation/désérialisation en Python
2import pickle
3
4# Sérialisation
5obj = {"key": "value"}
6serialized_obj = pickle.dumps(obj)
7
8# Désérialisation
9deserialized_obj = pickle.loads(serialized_obj)

Dans ce cas, si un attaquant peut contrôler les données désérialisées, il pourrait injecter du code malveillant et causer beaucoup de dommage à votre application.

9.2 Les recommandations de l'OWASP pour cette menace

OWASP, dans son top 10 des vulnérabilités, liste des recommandations pour lutter contre l'Insecure Deserialization. Voici quelques-unes de ces directives :

• Ne faites jamais confiance aveuglément aux données entrantes : Vérifiez toujours les sources de données que vous allez désérialiser et assurez-vous qu'elles sont sûres avant de les utiliser.

• Implémentez des contrôles d'accès appropriés : Assurez-vous que seules les personnes autorisées peuvent exécuter des opérations de désérialisation.

• Utilisez des formats de sérialisation simples : Préférez les formats de sérialisation moins complexes, comme JSON, qui sont plus difficiles à exploiter pour les attaquants.

• Mettez à jour vos bibliothèques de sérialisation : Gardez vos bibliothèques de sérialisation et désérialisation à jour pour bénéficier des derniers correctifs de sécurité.

Pour une compréhension plus approfondie et des exemples de codes, vous pouvez consulter l'OWASP Cheat Sheet consacrée à l'Insecure Deserialization.

Attention: La désérialisation insecure pose un risque sérieux et il est essentiel d'adopter des mesures de protection adaptées. Par sa nature technique, il est recommandé de consulter un expert en sécurité pour auditer et sécuriser les systèmes.

10. Menace N°9: Utilisation de composants avec des vulnérabilités connues

10.1 Comprendre cette menace

L'utilisation de composants avec des vulnérabilités connues est une menace répandue dans le développement web. Cela se produit lorsque les applications et les API utilisent des composants avec des vulnérabilités connues qui peuvent être exploitées par des attaquants.

Celle-ci est constituée de bibliothèques, cadres et autres modules logiciels que les développeurs intègrent à leurs applications. Cependant, si ces composants sont défectueux ou présentent des vulnérabilités, ils peuvent aussi présenter un risque pour l'application.

Remarque: Il est important de noter qu'une application peut être seulement aussi sécurisée que le composant logiciel le moins sécurisé.

Voici quelques conséquences potentielles de cette menace:

• Les informations sensibles peuvent être exposées
• L'application peut être rendue indisponible
• Les attaquants peuvent exécuter des commandes arbitraires sur le système

10.2 Les solutions de l'OWASP pour réduire le risque

L'OWASP recommande plusieurs stratégies pour atténuer cette menace:

1. Inventaire régulier des composants utilisés : Tenir à jour un inventaire détaillé de tous les composants utilisés, y compris la version, le fournisseur, et la raison de l'utilisation.

2. Garder les composants à jour : Assurer que tous les composants utilisés sont à jour et que les mises à jour de sécurité sont effectuées dès qu'elles sont disponibles.

3. Supprimer les composants inutilisés : Les composants qui ne sont plus utilisés doivent être supprimés de l'application pour réduire la surface d'attaque possible.

4. Utiliser des contrôles de sécurité lors de l'utilisation de composants tiers : Les contrôles de sécurité doivent être utilisés lors de l'utilisation de composants tiers pour garantir qu'ils ne présentent pas de vulnérabilités connues.

Pour mettre en exergue cette menace, examinons un exemple concret.

1// Code "inoffensif" d'inclusion d'un module tiers
2include 'module.php';

Dans cet exemple, si module.php contient une vulnérabilité, cela peut représenter une menace pour tout le système.

Donc, il est crucial de toujours vérifier les dependencies que vous utilisez, de les garder à jour et de faire un effort conscient pour comprendre les implications de sécurité de chaque composant logiciel. Un outil comme Dependabot peut être d'une grande aide pour automatiser ce processus.

Important: Pour se protéger contre cette menace, on peut aussi utiliser des outils de veille de sécurité comme Snyk ou le Security Advisory GitHub qui peuvent vous aider à identifier et résoudre les vulnérabilités des dépendances logicielles.