A05 : Injection

A05 : Injection Parcours Top 10 OWASP

Commencer

Décrypter la vulnérabilitéA05 : Injection

Les bons réflexes à adopter pour se protéger A05 : Injection

Je ne concatène jamais les entrées utilisateur

J'utilise des ORM ou moteurs de requêtes sécurisés​

J'encode les données selon le contexte​

Je valide toujours les entrées utilisateur​

Je limite les risques de XSS en n’injectant jamais de données dans du HTML brut

J'évite les fonctions dangereuses​

Choissisez la bonne réponse

1/2 Quelle condition est indispensable pour qu’une faille d’injection soit exploitable ?

A. L’application doit utiliser une base de données relationnelle.

B. Les données utilisateur sont insérées dans une requête sans filtrage ni paramétrage.

C. Le site doit être accessible en HTTP et non en HTTPS.

D. Le serveur doit fonctionner sous Linux.

Bravo ! Excellente réponse

✅La bonne réponse est la : (B). Pour qu’une faille d’injection soit exploitable, la condition indispensable est que les données fournies par l’utilisateur soient intégrées dans une requête sans filtrage ni utilisation de mécanismes de paramétrage. 👉 Une faille d’injection (comme une injection SQL) apparaît lorsqu’une application fait confiance à des données utilisateur sans les sécuriser. Concrètement, si une entrée utilisateur (formulaire, URL, champ de recherche…) est directement intégrée dans une requête sans : validation (filtrage), ni protection (requêtes paramétrées), alors un attaquant peut injecter du code malveillant. ❌(A) est une mauvaise réponse : l’application doit utiliser une base de données relationnelle. Les injections ne se limitent pas aux bases relationnelles (SQL). Il existe aussi : des injections NoSQL, des injections LDAP, des injections de commandes système, etc. ❌(C) est également une mauvaise réponse : le site doit être accessible en HTTP et non en HTTPS. HTTP vs HTTPS concerne le chiffrement des données en transit, pas leur traitement côté serveur. ❌(D) est aussi incorrecte : le serveur doit fonctionner sous Linux. Le système d’exploitation (Linux, Windows, etc.) n’a rien à voir avec la faille.Une injection dépend : du code de l’application, pas de l’OS sur lequel elle tourne.

Oups ! Mauvaise réponse

❌(A) : est une mauvaise réponse : l’application doit utiliser une base de données relationnelle.Les injections ne se limitent pas aux bases relationnelles (SQL). Il existe aussi : des injections NoSQL, des injections LDAP, des injections de commandes système, etc. ❌(C) est également une mauvaise réponse : le site doit être accessible en HTTP et non en HTTPS. HTTP vs HTTPS concerne le chiffrement des données en transit, pas leur traitement côté serveur. ❌(D) est aussi incorrecte : le serveur doit fonctionner sous Linux. Le système d’exploitation (Linux, Windows, etc.) n’a rien à voir avec la faille. Une injection dépend : du code de l’application, pas de l’OS sur lequel elle tourne. ✅La bonne réponse est la : (B). Pour qu’une faille d’injection soit exploitable, la condition indispensable est que les données fournies par l’utilisateur soient intégrées dans une requête sans filtrage ni utilisation de mécanismes de paramétrage. 👉Une faille d’injection (comme une injection SQL) apparaît lorsqu’une application fait confiance à des données utilisateur sans les sécuriser. Concrètement, si une entrée utilisateur (formulaire, URL, champ de recherche…) est directement intégrée dans une requête sans : validation (filtrage),ni protection (requêtes paramétrées), alors un attaquant peut injecter du code malveillant.

Choissisez la bonne réponse

2/2 : Pourquoi le Content Security Policy (CSP) est-il présenté comme une mesure de réduction d’impact et non comme une protection complète contre les XSS ?

A. Parce qu’il empêche uniquement les XSS stockées.

B. Parce qu’il ne fonctionne que sur certains navigateurs.

C. Parce qu’il limite ce qu’un script injecté peut faire, sans empêcher l’injection elle-même.

D. Parce qu’il remplace l’encodage des sorties HTML.

Excellente réponse !

✅La bonne réponse est la : (C). Le Content Security Policy (CSP) est considéré comme une mesure de réduction d’impact plutôt que comme une protection complète contre les XSS, car il limite les actions possibles d’un script malveillant sans empêcher son injection. 👉 Le CSP agit comme une “barrière de confinement” : il restreint les ressources qu’un script peut charger ou utiliser (scripts, domaines, inline, etc.) mais si une injection XSS existe dans le code, elle peut quand même se produire. ❌ (A) est une mauvaise réponse : parce qu’il empêche uniquement les XSS stockées. Le Content Security Policy ne cible pas uniquement les XSS stockées. ❌(B) est également une mauvaise réponse : parce qu’il ne fonctionne que sur certains navigateurs. Le Content Security Policy est largement supporté par les navigateurs modernes. ❌(D) est aussi incorrecte : parce qu’il remplace l’encodage des sorties HTML. Le Content Security Policy ne remplace pas les protections essentielles comme l’encodage des sorties.

Oups ! Mauvaise réponse

❌(A) est une mauvaise réponse : parce qu’il empêche uniquement les XSS stockées. Le Content Security Policy ne cible pas uniquement les XSS stockées. ❌(B) est également une mauvaise réponse : parce qu’il ne fonctionne que sur certains navigateurs. Le Content Security Policy est largement supporté par les navigateurs modernes. ❌(D) est aussi incorrecte : parce qu’il remplace l’encodage des sorties HTML. Le Content Security Policy ne remplace pas les protections essentielles comme l’encodage des sorties. ✅La bonne réponse est la : (C). Le Content Security Policy (CSP) est considéré comme une mesure de réduction d’impact plutôt que comme une protection complète contre les XSS, car il limite les actions possibles d’un script malveillant sans empêcher son injection. 👉Le CSP agit comme une “barrière de confinement” : il restreint les ressources qu’un script peut charger ou utiliser (scripts, domaines, inline, etc.) mais si une injection XSS existe dans le code, elle peut quand même se produire.

🎉 Vous avez terminé ce chapitre, bravo

A05 : Injection​​

Pour passer au chapitre suivant et découvrir les vulnérabilités du Top 10 OWASP cliquez simplement sur le bouton

SUIVANT

J'utilise des requêtes préparées, statements paramétrés (ex : ? en SQL, $1, :param...) pour éviter toute interprétation de données comme du code.

Je contrôle les entrées utilisateur en n’autorisant que les formats valides (ex : nombres avec parseInt, isNaN, e-mails, usernames avec regex stricte ou encore tailles maximales avec types MIME, etc).

Je protège les données en les encodant ou en les échappant selon leur usage (HTML, JavaScript, URL, LDAP, Shell).

Je privilégie des ORM ou moteurs de requêtes sécurisés pour générer mes requêtes (ex : SQLAlchemy, Doctrine, Hibernate, Mongoose) sans requêtes “raw” forcées.

Je bannis les fonctions dangereuses comme eval exec() ou system() avec des données non contrôlée. Dans le navigateur, j'évite innerHTML, document.write, outerHTML quand des données utilisateur sont impliquées​.

Je protège mes applications contre les XSS en encodant les données, en utilisant textContent ou setAttribute à la place de innerHTML et en activant une Content Security Policy (CSP).