Chapitre 7 — Codage Sécurisé, SQLi, XSS & Buffer Overflow

Les attaques d'injection et les vulnérabilités de code sont parmi les plus courantes. Ce module couvre le OWASP Top 10, les attaques par injection et les principes du codage sécurisé.

Injection SQL (SQLi)

Mémorisez ! SQLi = entrée utilisateur non validée insérée dans une requête SQL. Contre-mesure principale : requêtes paramétrées (prepared statements). La validation et l'échappement des entrées sont complémentaires mais pas suffisants seuls.

L'injection SQL se produit quand un attaquant insère du code SQL malveillant dans un champ de saisie pour manipuler la base de données.

Exemple SQLi :
Formulaire de connexion : SELECT * FROM users WHERE username='$user' AND password='$pass'
Attaquant entre comme username : ' OR '1'='1
Résultat : SELECT * FROM users WHERE username='' OR '1'='1' AND password=''
'1'='1' est toujours vrai → accès accordé sans mot de passe.

Types d'injection SQL

In-band SQLi : les résultats reviennent dans la réponse HTTP (Error-based, Union-based).
Blind SQLi : pas de données dans la réponse — déduction par questions vrai/faux (Boolean-based) ou délais (Time-based).
Out-of-band SQLi : exfiltration via DNS ou HTTP vers un serveur externe.

Contre-mesures SQLi : requêtes paramétrées (Prepared Statements), procédures stockées, ORM, validation des entrées, WAF, principle of least privilege sur le compte DB.

Cross-Site Scripting (XSS)

XSS permet à un attaquant d'injecter du code JavaScript malveillant dans une page web vue par d'autres utilisateurs.

Type XSS	Description	Persistance
Stored (Persistent)	Le script est stocké dans la base de données et exécuté pour chaque visiteur	Persistant — affecte tous les utilisateurs
Reflected (Non-Persistent)	Le script est reflété dans la réponse depuis l'URL/requête. La victime doit cliquer sur un lien malveillant.	Non persistant
DOM-based	Le script modifie le DOM côté client sans passer par le serveur	Côté client uniquement

Contre-mesures XSS : encodage des sorties (output encoding), Content Security Policy (CSP), validation des entrées, HttpOnly cookies (empêche JS d'accéder aux cookies), WAF.

Astuce Examen

CSP (Content Security Policy) est une des meilleures défenses contre XSS. En définissant une politique CSP stricte (ex: "n'exécuter que des scripts du même domaine"), même si un XSS est injecté, le navigateur refusera de l'exécuter.

Autres Injections

Command Injection : injection de commandes OS dans des paramètres traités par le système. Ex: filename.txt; rm -rf /. Contre-mesure : ne jamais passer des entrées utilisateur à des shells système.
LDAP Injection : injection dans des requêtes LDAP — similaire à SQLi mais pour les annuaires.
XML/XPath Injection : injection dans des requêtes XML pour accéder à des données non autorisées.
CSRF (Cross-Site Request Forgery) : forcer un utilisateur authentifié à exécuter des actions non souhaitées sur un site web en exploitant sa session active. Contre-mesure : tokens CSRF, SameSite cookies, vérification de l'origine (Referer/Origin header).

Buffer Overflow

Un buffer overflow se produit quand un programme écrit plus de données que la mémoire allouée peut en contenir — les données débordent dans des zones mémoire adjacentes.

Stack Buffer Overflow : débordement dans la pile (stack) — peut écraser l'adresse de retour et rediriger l'exécution vers du code malveillant.
Heap Buffer Overflow : débordement dans le tas (heap) — exploitation plus complexe.
Contre-mesures : ASLR (Address Space Layout Randomization — randomise l'emplacement en mémoire), DEP/NX (Data Execution Prevention — empêche l'exécution de code dans des zones de données), Stack Canaries (valeur sentinelle détectant les débordements), Bounds Checking (langages modernes).
Langages sûrs : Java, Python, Rust vérifient automatiquement les bornes — pas vulnérables. C/C++ sans protection le sont.

Principes de Codage Sécurisé

Validation des entrées : valider TOUTES les entrées utilisateur (type, longueur, format). Whitelist (accepter uniquement ce qui est connu bon) > Blacklist (bloquer ce qui est connu mauvais).
Encodage des sorties : encoder les données avant de les afficher dans HTML, JS, SQL.
Requêtes paramétrées : séparent le code SQL des données — l'entrée ne peut jamais modifier la structure de la requête.
Moindre privilège : les comptes de DB ne doivent avoir que les droits nécessaires (SELECT uniquement si lecture seule).
Gestion sécurisée des erreurs : ne jamais exposer les erreurs techniques aux utilisateurs (stack traces, messages SQL) — ils donnent des informations aux attaquants.
Chiffrement des données sensibles : jamais de mots de passe en clair, hachage avec sel.
Code Review / SAST : analyse statique du code source pour détecter les vulnérabilités avant déploiement.
DAST (Dynamic Application Security Testing) : tests de sécurité dynamiques sur l'application en fonctionnement.

Quiz — Web & Code

1. Quelle est la contre-mesure la plus efficace contre l'injection SQL ?

Valider la longueur des entrées uniquement Utiliser des requêtes paramétrées (Prepared Statements) Déployer un antivirus sur le serveur de base de données Chiffrer la base de données

Les Prepared Statements (requêtes paramétrées) séparent le code SQL des données. L'entrée utilisateur ne peut jamais être interprétée comme du code SQL — elle est toujours traitée comme une donnée. C'est la seule protection vraiment efficace contre SQLi.

2. Un XSS "Stored" (persistant) est plus dangereux qu'un XSS "Reflected" car :

Il exploite des vulnérabilités dans le navigateur lui-même Il nécessite moins de compétences techniques Le script malveillant est stocké sur le serveur et exécuté pour TOUS les visiteurs, sans qu'ils aient besoin de cliquer sur un lien spécial Il contourne les WAF plus facilement

XSS Stored = le script est sauvegardé dans la base de données (ex: commentaire de blog avec du JS). Chaque utilisateur qui visite la page l'exécute automatiquement. Un attaquant peut compromettre des milliers d'utilisateurs sans cibler chacun individuellement.

3. Un buffer overflow permet à un attaquant de :

Injecter du code SQL dans une base de données Intercepter des communications chiffrées Usurper l'identité d'un utilisateur sur un site web Écraser des données mémoire adjacentes et potentiellement exécuter du code arbitraire en redirectionnant le flux d'exécution

Buffer overflow : écrire plus que la taille du buffer alloué déborde dans la mémoire adjacente. Sur la stack, cela peut écraser l'adresse de retour (return address) et rediriger l'exécution vers le shellcode de l'attaquant — exécution de code à distance.

4. ASLR (Address Space Layout Randomization) est une protection contre :

Les buffer overflows — en randomisant les adresses mémoire, l'attaquant ne peut pas prédire où son shellcode sera en mémoire Les attaques d'injection SQL Les attaques XSS Les attaques DDoS

ASLR randomise l'emplacement de la pile, du tas et des bibliothèques partagées à chaque démarrage. Un exploit de buffer overflow qui suppose des adresses mémoire fixes échouera car les adresses sont différentes à chaque exécution. Doit être combiné avec DEP/NX pour une protection complète.

5. CSRF (Cross-Site Request Forgery) exploite :

Une vulnérabilité dans le navigateur web lui-même Le fait que l'utilisateur utilise un mot de passe faible La session authentifiée d'un utilisateur pour lui faire exécuter des actions non désirées sur un site web de confiance Une injection SQL dans les tokens de session

CSRF : une page malveillante déclenche une requête vers un site où l'utilisateur est connecté (ex: virement bancaire). Le navigateur inclut automatiquement les cookies de session — le site cible pense que la requête vient de l'utilisateur. Contre-mesure : tokens CSRF uniques par formulaire.

6. La CSP (Content Security Policy) est particulièrement efficace contre :

Les attaques DDoS Les attaques XSS en spécifiant quelles sources de scripts sont autorisées à s'exécuter L'injection SQL Les buffer overflows

CSP = header HTTP définissant une whitelist des sources autorisées pour les scripts, styles, images. Même si un XSS est injecté dans la page, le navigateur refusera d'exécuter un script qui ne correspond pas à la politique CSP. Réduction significative de la surface d'attaque XSS.

7. La "whitelist validation" est préférable à la "blacklist validation" pour les entrées utilisateur car :

Elle est plus rapide à implémenter Elle permet plus de flexibilité pour les utilisateurs Elle est compatible avec tous les navigateurs Elle définit ce qui est autorisé, empêchant les attaques avec des caractères ou techniques non prévues — contrairement à la blacklist qui peut rater des variantes

Blacklist = bloquer ce qui est connu mauvais. Problème : il est impossible de lister toutes les variantes d'attaque. Un attaquant peut encoder autrement, utiliser des caractères Unicode, etc. Whitelist = n'accepter que ce qui est connu bon (ex: champs de nom = seulement lettres et espaces) — beaucoup plus robuste.

8. Le DEP/NX (Data Execution Prevention / No-eXecute) protège contre les buffer overflows en : Marquant certaines zones mémoire (données/pile) comme non-exécutables, empêchant l'exécution du shellcode de l'attaquant Randomisant les adresses mémoire Chiffrant la mémoire du programme Limitant la taille des buffers alloués

DEP/NX marque les pages mémoire de données (stack, heap) comme non-exécutables. Même si un attaquant y écrit son shellcode via un buffer overflow, le CPU refusera de l'exécuter. ASLR + DEP = deux couches de protection complémentaires.

9. Un test DAST (Dynamic Application Security Testing) est effectué : En analysant le code source sans l'exécuter En modélisant les menaces en phase de conception Sur l'application en cours d'exécution, en simulant des attaques de l'extérieur (boîte noire) En validant la configuration des dépendances logicielles

DAST = test dynamique sur app en fonctionnement (black box). Simule des attaques réelles (SQLi, XSS, etc.) sur l'application déployée. SAST = analyse statique du code source (white box). Les deux se complémentent dans un SDLC sécurisé.

10. Pourquoi les langages comme Java et Python sont-ils moins vulnérables aux buffer overflows que C/C++ ? Ils utilisent des compilateurs plus récents Ils incluent une gestion automatique de la mémoire et des vérifications de bornes qui empêchent les débordements Ils ne permettent pas d'accéder au réseau Ils utilisent ASLR par défaut

Java, Python, Go, Rust gèrent la mémoire automatiquement (garbage collection) et vérifient les bornes des tableaux. Une tentative d'écriture hors bornes lève une exception, pas un débordement silencieux. C/C++ font confiance au programmeur pour gérer la mémoire — une erreur = vulnérabilité potentielle.