1. Le Standard OWASP Top 10 (2021) - Analyse Approfondie

L'OWASP (Open Web Application Security Project) publie le "Top 10" des vulnérabilités critiques, basé sur l'analyse de plus de 500 000 applications.

Ci-dessous, chaque vulnérabilité est décortiquée avec son contexte historique et son impact financier.

A01:2021 - Broken Access Control (Contrôle d'accès défaillant)

Mécanisme : La faille survient quand les restrictions d'accès ne sont pas appliquées côté serveur. L'attaquant peut agir en tant qu'administrateur ou accéder aux données d'autrui (IDOR).

💡 Cas Historique : Facebook (2018) Une faille dans la fonctionnalité "Voir en tant que" a permis de voler les tokens d'accès de 50 millions de comptes. 💰 Coût estimé : Facebook a risqué une amende RGPD de 1,6 milliard de dollars (4% de son CA mondial). L'action a chuté de 3% immédiatement après l'annonce.

Comment s'en prémunir ?

• Ne jamais faire confiance aux ID dans l'URL (/user/123).
• Vérifier systématiquement les droits d'accès côté serveur (ex: if (user.id != resource.owner_id) deny()).
• Désactiver l'accès direct aux répertoires et fichiers sensibles (.git, backup).

Questions de compréhension :

1. Si je change id=123 par id=124 dans l'URL et que j'accède à la facture d'un autre client, comment s'appelle cette vulnérabilité spécifique ?
2. Quelle est la différence entre l'authentification (qui je suis) et l'autorisation (ce que j'ai le droit de faire) ?
3. Pourquoi cacher un bouton "Admin" dans l'interface (CSS display: none) n'est-il pas une mesure de sécurité suffisante ?

A02:2021 - Cryptographic Failures (Défaillances cryptographiques)

Mécanisme : Protection insuffisante des données sensibles (mots de passe, CB, santé) au repos ou en transit (HTTP, algorithmes faibles).

💡 Cas Historique : Adobe (2013) 153 millions de comptes compromis car les mots de passe étaient chiffrés (réversibles) au lieu d'être hachés. 💰 Coût estimé : Adobe a payé 1,1 million de dollars en frais juridiques et une somme non divulguée pour régler les plaintes des clients, sans compter l'impact massif sur sa réputation.

Comment s'en prémunir ?

• Stocker les mots de passe avec des algorithmes de hachage lents et robustes (Argon2, bcrypt).
• Utiliser systématiquement HTTPS (TLS) pour tous les échanges.
• Ne jamais stocker de données sensibles (CB) si ce n'est pas indispensable.

Questions de compréhension :

1. Pourquoi l'algorithme de hachage MD5 est-il considéré comme obsolète pour stocker des mots de passe ?
2. Quel protocole sécurisé (utilisant le port 443) doit impérativement remplacer HTTP ?
3. Qu'est-ce que le "Salt" (sel) et pourquoi est-il indispensable lors du hachage des mots de passe ?

A03:2021 - Injection

Mécanisme : Des données non fiables sont envoyées à un interpréteur (SQL, OS, LDAP) comme une commande. L'interpréteur ne distingue pas la donnée du code.

💡 Cas Historique : TalkTalk (2015) Une injection SQL sur une page web obsolète a permis le vol des données de 157 000 clients. 💰 Coût estimé : L'entreprise a perdu 101 000 clients et a dû payer une amende record de 400 000 £ à l'époque, pour un coût total de remédiation de 77 millions de livres.

Comment s'en prémunir ?

• Utiliser des requêtes préparées (Prepared Statements) en SQL.
• Valider strictement les entrées utilisateurs (Allowlist).
• Utiliser un ORM (Entity Framework, Hibernate, Eloquent) qui gère l'échappement automatiquement.

Questions de compréhension :

1. Dans l'expression ' OR '1'='1, quel est le rôle des guillemets simples ?
2. Quelle instruction SQL permet souvent de combiner les résultats de deux tables lors d'une injection ?
3. Pourquoi la validation côté client (Javascript) ne protège-t-elle pas contre les injections SQL ?

A04:2021 - Insecure Design (Conception non sécurisée)

Mécanisme : Lacune dans l'architecture ou les règles métier. "On ne peut pas coder de manière sécurisée une conception défaillante".

💡 Cas Historique : Parler (2021) Des hacktivistes ont aspiré 99% des données du site car les posts avaient des IDs séquentiels non protégés. 💰 Coût estimé : Fermeture complète du service pendant plusieurs semaines, perte totale de confiance des investisseurs et retrait des stores Apple/Google.

Comment s'en prémunir ?

• Adopter une approche "Security by Design" dès le début du projet.
• Modéliser les menaces (Threat Modeling) avant de coder.
• Éviter les ID séquentiels prévisibles (utiliser des UUID).

Questions de compréhension :

1. Quel est le principe de la "défense en profondeur" (Defense in Depth) ?
2. Donnez un exemple de fonctionnalité "pratique" pour l'utilisateur mais dangereuse par conception (ex: récupération de compte).
3. Qu'est-ce que le "Rate Limiting" et quelle attaque de conception permet-il d'atténuer ?

A05:2021 - Security Misconfiguration (Mauvaise configuration)

Mécanisme : Systèmes installés avec les paramètres par défaut, stockage cloud ouvert, messages d'erreurs verbeux.

💡 Cas Historique : Twitch (2021) Une erreur de configuration serveur a exposé 125 Go de données, incluant tout le code source et les revenus des streamers. 💰 Coût estimé : Impact inestimable sur la propriété intellectuelle. Les revenus des streamers étant publics, cela a créé des tensions majeures au sein de la communauté.

Comment s'en prémunir ?

• Désactiver les comptes et services par défaut inutilisés.
• Configurer les headers de sécurité HTTP (HSTS, X-Frame-Options).
• Ne jamais exposer les messages d'erreur détaillés (Stack Trace) en production.

Questions de compréhension :

1. Pourquoi est-il crucial de changer les mots de passe par défaut des équipements (routeurs, serveurs) ?
2. Quelle est la règle d'or concernant les messages d'erreur affichés aux utilisateurs ?
3. Citez une "bonne pratique" simple pour sécuriser l'accès à un dossier d'administration.

A06:2021 - Vulnerable and Outdated Components

Mécanisme : Utilisation de bibliothèques tierces contenant des failles connues (CVE).

💡 Cas Historique : Equifax (2017) 147 millions de clients impactés par une faille dans le framework Apache Struts, patchée 2 mois avant l'attaque mais non appliquée. 💰 Coût estimé : Equifax a accepté de payer jusqu'à 700 millions de dollars pour régler les poursuites judiciaires liées à cette négligence.

Comment s'en prémunir ?

• Faire un inventaire des composants (SCA - Software Composition Analysis).
• Automatiser la détection des vulnérabilités (ex: npm audit, OWASP Dependency Check).
• Mettre à jour régulièrement les dépendances.

Questions de compréhension :

1. Qu'est-ce qu'une CVE (Common Vulnerabilities and Exposures) ?
2. Pourquoi faut-il maintenir son système (OS et logiciels) à jour régulièrement ?
3. Quel fichier liste souvent les dépendances d'un projet web (PHP ou JS) ?

A07:2021 - Identification and Authentication Failures

Mécanisme : Faiblesses dans la vérification de l'identité : mots de passe faibles, absence de MFA, gestion de session.

💡 Cas Historique : Nintendo (2020) 300 000 comptes piratés via du "Credential Stuffing" (utilisation de mots de passe volés sur d'autres sites). 💰 Coût estimé : Remboursement massif des achats frauduleux effectués sur l'eShop et coût de support technique pour réinitialiser les comptes manuellement.

Comment s'en prémunir ?

• Mettre en place l'authentification multifacteur (MFA/2FA).
• Interdire les mots de passe faibles ou compromis (liste des 10 000 pires mots de passe).
• Limiter le nombre de tentatives de connexion (Rate Limiting).

Questions de compréhension :

1. Qu'est-ce que l'attaque par "Credential Stuffing" ?
2. Pourquoi limiter le nombre de tentatives de connexion (ex: 5 essais max) est-il crucial ?
3. Quel mécanisme (souvent via smartphone) ajoute une couche de sécurité au-delà du mot de passe ?

A08:2021 - Software and Data Integrity Failures

Mécanisme : Mises à jour non signées, pipelines CI/CD compromis, désérialisation non sécurisée.

💡 Cas Historique : SolarWinds (2020) Une mise à jour officielle corrompue a infecté 18 000 clients, dont le Trésor américain et Microsoft. 💰 Coût estimé : Coût global de remédiation pour les entreprises et gouvernements estimé à plus de 100 milliards de dollars.

Comment s'en prémunir ?

• Signer numériquement tout code ou artefact produit.
• Vérifier l'intégrité des logiciels téléchargés (checksums, signatures GPG).
• Sécuriser la chaîne CI/CD (intégration continue).

Questions de compréhension :

1. Pourquoi est-il important de vérifier la signature numérique (GPG) d'un logiciel avant de l'installer ?
2. Dans une attaque "Supply Chain" (chaîne d'approvisionnement), qui est la cible initiale de l'attaquant ?
3. Qu'est-ce que la désérialisation d'un objet ?

A09:2021 - Security Logging and Monitoring Failures

Mécanisme : Absence de logs sur les événements critiques ou logs inexploitables.

💡 Cas Historique : Marriott (2018) Des attaquants ont eu accès aux données de 500 millions de clients pendant 4 ans sans être détectés. 💰 Coût estimé : Marriott a été condamné à une amende de 18,4 millions de livres par l'ICO (UK) et a dépensé des dizaines de millions en frais de justice.

Comment s'en prémunir ?

• Centraliser les logs sur un serveur sécurisé et indépendant.
• Logger les événements critiques (échecs de connexion, accès admin).
• Mettre en place des alertes en temps réel.

Questions de compréhension :

1. Quels sont les 4 éléments clés qu'un bon log doit contenir (Qui... ?) ?
2. Pourquoi faut-il envoyer les logs vers un serveur externe sécurisé plutôt que de les garder uniquement en local ?
3. Quel est le risque principal si une intrusion n'est pas détectée rapidement ?

A10:2021 - Server-Side Request Forgery (SSRF)

Mécanisme : L'attaquant force le serveur à effectuer des requêtes HTTP vers une destination interne non exposée.

💡 Cas Historique : Capital One (2019) Une faille SSRF a permis de voler les données de 100 millions de clients sur des serveurs AWS S3. 💰 Coût estimé : L'entreprise a écopé d'une amende de 80 millions de dollars et a dépensé environ 150 millions en frais de remédiation et de notification.

Comment s'en prémunir ?

• Valider et filtrer toutes les URL fournies par l'utilisateur.
• Utiliser une liste blanche (Allowlist) de domaines autorisés.
• Désactiver les redirections HTTP sur le serveur qui effectue les requêtes.

Questions de compréhension :

1. Dans une faille SSRF, qui effectue la requête malveillante : le navigateur du client ou le serveur web ?
2. Citez une ressource interne sensible qu'un attaquant pourrait viser via SSRF (ex: Cloud).
3. Comment le filtrage des URL en entrée (Allowlist) peut-il protéger contre cette faille ?