CompTIA SY0-701: Sécurité des applications et du web — Guide d'étude

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fait partie du CompTIA Security+ SY0-701 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens CompTIA, ou passez des tests chronométrés sur ExamRoll.io.

Les applications modernes se situent au carrefour de la logique métier, des données sensibles et des entrées utilisateur non fiables. Parce que les frontends web et mobiles sont exposés à l’ensemble d’Internet, ils représentent l’une des surfaces d’attaque les plus vastes et les plus constamment exploitées de toute entreprise. Leur défense nécessite des contrôles en couches qui commencent par la manière dont le code est écrit et s’étendent aux protections à l’exécution, à la vérification de l’intégrité et aux tests continus.

Attaques par injection

L’injection reste la vulnérabilité web archétypale. Elle se produit chaque fois qu’une application concatène une entrée non fiable dans une chaîne destinée à un interpréteur — une requête SQL, une commande shell, un filtre LDAP, un analyseur XML ou un moteur de modèles — sans séparer correctement le code des données. Dans une injection SQL (SQLi), un attaquant manipule une requête pour que la base de données exécute une logique contrôlée par l’attaquant. Un modèle vulnérable classique en PHP ressemble à ceci :

$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";

Soumettre admin' OR '1'='1 transforme la requête en une tautologie qui renvoie toutes les lignes. Des variantes plus avancées incluent l’extraction basée sur UNION (' UNION SELECT credit_card FROM payments--), l’inférence booléenne ou temporelle en aveugle (' AND SLEEP(5)--), et l’exfiltration hors bande (out-of-band) par le biais de rappels DNS. La solution définitive réside dans les requêtes paramétrées ou les instructions préparées, qui envoient le modèle de requête et ses paramètres à la base de données en tant que structures distinctes :

cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))

L’injection de commandes suit le même schéma mais cible le shell du système d’exploitation. Du code comme os.system("ping " + host) permet à un attaquant de soumettre 8.8.8.8; cat /etc/passwd et d’exécuter des commandes arbitraires. La remédiation exige d’éviter complètement l’invocation du shell, d’utiliser des API qui acceptent des tableaux d’arguments (subprocess.run(["ping", host], shell=False)), et d’appliquer une validation stricte par liste blanche (allow-list) à toute valeur qui doit atteindre un shell.

Cross-Site Scripting et CSRF

Le Cross-Site Scripting (XSS) est l’injection de script malveillant dans des pages rendues par une application de confiance, amenant le navigateur de la victime à exécuter du code de l’attaquant dans l’origine du site. Le XSS réfléchi renvoie des charges utiles (payloads) via un paramètre vulnérable ; le XSS stocké persiste la charge utile dans la base de données et la délivre à chaque visiteur ; le XSS basé sur le DOM se produit entièrement dans le JavaScript côté client qui écrit des données non fiables dans innerHTML, document.write, ou des récepteurs (sinks) similaires. Les conséquences vont du détournement de session (session hijacking) et de l’enregistrement de frappe (keylogging) à la prise de contrôle complète du compte par le biais d’actions forcées.

La Cross-Site Request Forgery (CSRF) est une attaque distincte mais complémentaire. Elle abuse de l’inclusion automatique des cookies par le navigateur pour tromper un utilisateur authentifié et lui faire soumettre une requête non désirée — par exemple, un formulaire caché sur un site malveillant qui effectue un POST vers bank.com/transfer. Les défenses incluent les jetons synchroniseurs (synchronizer tokens), qui sont des valeurs aléatoires par session intégrées dans les formulaires et vérifiées côté serveur, l’attribut de cookie SameSite=Lax ou SameSite=Strict, et l’exigence d’une ré-authentification pour les actions sensibles. Le XSS et la CSRF sont souvent confondus, mais le XSS exécute du code dans le navigateur de la victime tandis que la CSRF fait simplement en sorte que le navigateur émette une requête ; il est à noter qu’une attaque XSS réussie peut déjouer la plupart des défenses CSRF.

Codage sécurisé : Validation des entrées vs. Encodage des sorties

Deux contrôles sont fréquemment confondus, pourtant ils résolvent des problèmes différents. La validation des entrées (input validation) garantit que les données sont conformes à la structure attendue — longueur, type, jeu de caractères, plage, format — avant que l’application n’agisse dessus. Elle doit avoir lieu sur le serveur, en utilisant des listes blanches (allow-lists) chaque fois que possible (^[A-Za-z0-9_]{3,20}$ pour un nom d’utilisateur). La validation côté client à l’aide de JavaScript n’est qu’une fonctionnalité d’ergonomie ; elle peut être contournée avec n’importe quel proxy HTTP et ne doit jamais constituer la barrière de sécurité.

L’encodage des sorties (output encoding) garantit que les données sont affichées en toute sécurité dans n’importe quel contexte où elles sont injectées. La même chaîne de caractères qui est une entrée parfaitement valide peut nécessiter un traitement différent selon sa destination : le contexte du corps HTML nécessite un encodage des entités HTML (< → <), le contexte d’un attribut nécessite un encodage d’attribut entre guillemets, le contexte JavaScript nécessite un échappement \xHH, et les URL requièrent un encodage en pourcentage (percent-encoding). Un nom d’utilisateur comme O'Brien est une entrée légitime mais doit être encodé en O'Brien lorsqu’il est placé dans du HTML. La validation des entrées ne peut pas remplacer l’encodage des sorties, et l’encodage ne peut pas remplacer la validation — ils traitent des problèmes différents à différents moments du cycle de vie des données.

Le renforcement supplémentaire inclut les en-têtes Content Security Policy (CSP) pour restreindre les sources de scripts, les attributs (flags) HttpOnly et Secure sur les cookies de session, et les API paramétrées à chaque frontière de confiance (trust boundary).

WAFs et protections pour le téléversement de fichiers

Un pare-feu d’application web (WAF) inspecte le trafic HTTP et bloque les requêtes correspondant à des schémas malveillants connus — signatures de SQLi, charges utiles XSS, séquences de traversée de répertoire (path traversal), anomalies de protocole. Déployé en tant que proxy inverse (ModSecurity avec l’OWASP Core Rule Set, AWS WAF, Cloudflare, F5), il fournit un correctif virtuel (virtual patching) précieux lorsqu’une vulnérabilité est découverte avant que le code ne puisse être corrigé. Cependant, un WAF est un contrôle compensatoire, pas un substitut à un codage sécurisé. Les attaquants sophistiqués contournent régulièrement les WAF par des astuces d’encodage, la pollution de paramètres HTTP (HTTP parameter pollution) et la fragmentation des charges utiles (payloads).

Le téléversement de fichiers (file uploads) mérite une attention particulière car il combine du contenu non fiable avec un stockage côté serveur et, souvent, une exécution. Les protections incluent la validation du type de fichier en inspectant les octets magiques (magic bytes) plutôt qu’en se fiant à l’extension ou à l’en-tête Content-Type, le stockage des fichiers téléversés en dehors de la racine web (web root), le renommage des fichiers avec des identifiants générés par le serveur (pour empêcher la traversée de répertoire via des noms de fichiers malicieux), l’analyse par un antivirus avant le stockage, et la diffusion du contenu téléversé par les utilisateurs depuis un domaine distinct pour empêcher l’exécution de scripts de même origine (same-origin script execution).

Scénario pratique : Injection SQL menant à la compromission totale d’une base de données

Le point de terminaison de recherche de produits d’une entreprise de vente au détail acceptait un paramètre category qui était directement concaténé dans une requête SQL sans assainissement. Un chercheur en sécurité a découvert que la soumission de ' UNION SELECT table_name,null,null FROM information_schema.tables-- renvoyait une liste de toutes les tables de la base de données dans la réponse. Des requêtes ultérieures ont extrait la table customers, révélant 1,2 million d’enregistrements, y compris des noms, des adresses e-mail et des mots de passe hachés avec bcrypt. L’attaquant a également découvert une procédure stockée qui pouvait être invoquée via l’injection SQL pour écrire des fichiers à la racine web, permettant le déploiement d’un webshell et la compromission totale du serveur. La vulnérabilité était présente depuis trois ans et avait été manquée lors de deux tests d’intrusion précédents, car les testeurs n’avaient testé que le formulaire de connexion, et non le point de terminaison de recherche. La leçon : les tests d’injection doivent couvrir chaque paramètre de chaque point de terminaison, et pas seulement les chemins d’authentification évidents.

← Réponse aux incidents · Tous les domaines · Sécurité du Cloud →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →