Sécurité appliquée · L3 · Section 1/5
Principes et modèle de menace
Progression
#Principes et modèle de menace
La sécurité informatique repose sur des principes directeurs et sur une démarche d'analyse des menaces. Un modèle de menace identifie les risques avant de choisir les contre-mesures; les principes guident ensuite la conception pour que ces contre-mesures tiennent dans la durée.
Prérequis
- Vocabulaire client/serveur et bases de données (module reseaux-web).
- Lecture fluide de petits programmes Python.
Objectifs d'apprentissage
- Définir risque, actif, attaquant et surface d'attaque pour un système donné.
- Appliquer les principes de moindre privilège, défense en profondeur et séparation des responsabilités.
- Conduire une analyse STRIDE sur une application concrète et proposer des mitigations proportionnées.
#Risques, actifs, attaquants, surfaces d'attaque
Un risque combine une vulnérabilité (faiblesse), une menace (quelqu'un ou quelque chose qui l'exploite) et un impact (dommage sur un actif). On le formule souvent: risque = probabilité d'exploitation x impact.
Un actif est toute ressource ayant de la valeur: données personnelles, secrets techniques, disponibilité d'un service, réputation. Définir les actifs est la première étape: sans liste d'actifs, on ne sait pas ce qu'on protège ni où arrêter.
Un attaquant (threat actor) est une entité qui tente d'exploiter une vulnérabilité: script kiddie opportuniste, criminel organisé, concurrent, insider malveillant, ou simplement un utilisateur maladroit. La question clé: quelles sont ses capacités et sa motivation ? Un attaquant opportuniste renonce devant une simple difficulté; un attaquant ciblé cherchera une faille logique au-delà des erreurs de configuration.
Une surface d'attaque est l'ensemble des points d'entrée exploitables: endpoints HTTP, champs de formulaire, dépendances, fichiers uploadés, interface d'administration, employés (ingénierie sociale). La réduire (supprimer les fonctionnalités inutiles, fermer les ports, restreindre les origins CORS) diminue mécaniquement le risque.
#Principes de sécurité
#Moindre privilège
Un utilisateur, un processus ou un service ne doit disposer que des droits strictement nécessaires, pendant la durée nécessaire. En pratique pour un serveur applicatif: compte dédié sans shell, accès à la seule base nécessaire, jetons aux scopes minimaux, élévation ponctuelle et journalisée (via sudo, pas via un compte root permanent).
Exemple concret: un service qui lit une table n'a pas besoin du droit DROP. Si une injection SQL survient malgré tout, l'attaquant récupère au plus cette table, sans pouvoir effacer le schéma.
#Défense en profondeur
Plusieurs couches indépendantes, chacune susceptible d'arrêter ou de retarder une attaque: pare-feu, segmentation réseau, validation des entrées, requêtes préparées, contrôle d'accès en base, chiffrement au repos, journalisation avec alertes. Le critère qualité: que se passe-t-il si une couche tombe ? Si la réponse est « compromission totale », la défense n'est pas en profondeur.
#Séparation des préoccupations
Isoler les fonctions pour limiter le rayon d'une compromission: environnements développement/test/production séparés (pas de données réelles en dev), services cloisonnés par rôle (pas de base de données joignable depuis Internet), séparation des comptes machine et humain. Un service exposé attire l'attention des attaquants; le cloisonnement empêche la propagation latérale.
#Modèle de menace STRIDE
STRIDE catégorise les menaces en six familles, chacune ciblant une propriété de sécurité:
| Lettre | Menace | Propriété visée | Question à se poser |
|---|---|---|---|
| S | Spoofing (usurpation d'identité) | Authenticité | Peut-on se faire passer pour quelqu'un d'autre ? |
| T | Tampering (altération) | Intégrité | Peut-on modifier des données en silence ? |
| R | Repudiation (répudiation) | Non-répudiation | L'auteur d'une action peut-il la nier ? |
| I | Information Disclosure | Confidentialité | Peut-on lire ce qui devrait être protégé ? |
| D | Denial of Service | Disponibilité | Peut-on bloquer le service à moindre frais ? |
| E | Elevation of Privilege | Autorisation | Un utilisateur simple peut-il devenir admin ? |
La méthode marche parce qu'elle est systématique: on ne cherche pas « des » failles, on parcourt six questions sur chaque composant. On obtient un tableau exploitable, pas une intuition.
#Exemple complet: banque en ligne
| Menace STRIDE | Exemple concret | Mitigation |
|---|---|---|
| Spoofing | Usurpation de compte par mot de passe volé | Authentification forte (MFA), détection de nouveaux appareils |
| Tampering | Modification d'un montant en transit ou en base | TLS, HMAC/signatures, contraintes d'intégrité en base |
| Repudiation | Nier avoir effectué un virement | Journal d'audit horodaté et inaltérable, confirmation explicite |
| Information Disclosure | Fuite de données personnelles via API | Autorisation par ressource, minimisation des champs retournés, chiffrement au repos |
| Denial of Service | Surcharge du serveur d'authentification | Limitation de débit, files avec quota, cache, CDN |
| Elevation of Privilege | Accès aux fonctions admin via IDOR | Contrôles côté serveur à chaque requête, tests d'autorisation |
#Exercice 1: analyser un code vulnérable
Voici un code de connexion. Identifiez les menaces au sens STRIDE avant de lire la correction.
1# Code vulnérable: à ne jamais mettre en production2username = request.form['username']3password = request.form['password']4query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"5cursor.execute(query)6user = cursor.fetchone()#Piste de correction
- Injection SQL (Tampering, Elevation of Privilege): la concaténation place des données dans le code SQL. Avec
' OR '1'='1' --en username, la requête renvoie le premier utilisateur. Correction: requête préparée avec paramètres (cursor.execute("... WHERE username=%s AND password=%s", (username, password))). - Information Disclosure (hypothèse à vérifier): si la table stocke les mots de passe en clair, toute fuite de base est critique. On ne peut pas le prouver depuis ce seul extrait; la vraie correction utilise un hachage adaptatif salé (Argon2id, bcrypt, scrypt).
- Repudiation: aucune trace des tentatives de connexion (réussies ou échouées). Ajouter un journal: horodatage, identifiant tenté, résultat, adresse source.
- Spoofing facilité: aucun verrouillage ni limitation de débit, ce qui permet une énumération de comptes par force brute. Ajouter limitation de débit et verrouillage progressif.
Notez la démarche: chaque menace nomme la propriété violée et la correction attaque la cause (mélange données/code), pas le symptôme (filtrer les guillemets).
#Exercice 2: STRIDE sur une application de chat
L'application permet aux utilisateurs de s'inscrire, de rejoindre des canaux publics, d'envoyer des messages en temps réel (WebSocket) et de chatter en privé avec leurs amis.
#Instructions
- Identifiez les composants: clients, serveur de chat, base de données, passerelle WebSocket.
- Pour chaque composant, parcourez les six lettres STRIDE et retenez les menaces plausibles.
- Proposez pour chaque menace retenue une mitigation proportionnée, en précisant le niveau concerné (primitive, protocole ou application).
#Exemple de correction partielle
| Composant | Menace STRIDE | Description | Mitigation |
|---|---|---|---|
| Serveur de chat | Spoofing | Usurpation d'identité d'un utilisateur (vol de jeton WebSocket) | Authentification par jeton court à durée de vie limitée, reconnexion obligatoire périodique |
| Base de données | Tampering | Modification silencieuse de messages ou de comptes | Contrôles d'accès par rôle, journal d'audit des écritures, sauvegardes vérifiées |
| Serveur de chat | Repudiation | Nier avoir envoyé un message offensant | Horodatage serveur des messages, conservation bornée pour respecter la vie privée |
| Base de données | Information Disclosure | Fuite de messages privés | Chiffrement au repos, accès par le service uniquement, minimisation des métadonnées |
| Serveur de chat | Denial of Service | Inondation de messages ou de connexions | Limitation de débit par utilisateur et par canal, quota de messages, contrôles anti-flood sur WebSocket |
| Clients | Elevation of Privilege | Utilisateur simple devenant modérateur via appel admin direct | Vérification du rôle côté serveur à chaque requête, jamais dans le seul client |
#À compléter vous-même
Complétez le tableau pour la passerelle WebSocket (que se passe-t-il si un client usurpe l'identité d'un autre utilisateur dans un canal ?) et pour le flux d'inscription (bot créant des milliers de comptes). Vérifiez votre tableau: chaque ligne doit nommer un composant précis, une menace STRIDE identifiable et une mitigation applicable sans détruire la fonctionnalité.