0Pricing
Cyber Security Academy · Leçon

Défense contre l’injection SQL

Prévenir les attaques par injection

Défense contre l’injection SQL est une leçon Cyber Security Academy gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Cyber Security Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Cyber Security Academy comprend 4 leçons au total.

Qu'est-ce que l'injection SQL

L'injection SQL (SQLi) se produit lorsqu'une entrée utilisateur non fiable est concaténée directement dans une requête SQL. L'attaquant introduit une syntaxe SQL dans un champ que l'application s'attend à recevoir comme de simples données, ce qui modifie le sens de la requête.

Cette vulnérabilité reste l'une des plus dommageables du Web, car elle peut divulguer des bases de données entières, contourner les connexions ou détruire des données.

Une requête vulnérable

L'erreur classique consiste à concaténer des chaînes. Si l'entrée est tom, la requête est correcte, mais une entrée conçue à cet effet réécrit la logique.

  • Le guillemet simple ferme la chaîne prématurément.
  • Tout ce qui suit devient du SQL exécutable.
query = "SELECT * FROM users WHERE name = '" + userInput + "'";
// userInput = tom' OR '1'='1
// becomes: SELECT * FROM users WHERE name = 'tom' OR '1'='1'

Contournement de l'authentification

Les formulaires de connexion sont une cible privilégiée. En injectant une condition toujours vraie et en neutralisant le reste, un attaquant se connecte sans mot de passe.

La séquence -- transforme la clause restante en commentaire, si bien que la vérification du mot de passe est ignorée.

-- attacker enters in the username field:
admin' --
-- resulting query:
SELECT * FROM users WHERE user = 'admin' --' AND pass = '...'

Requêtes paramétrées

La principale défense repose sur les requêtes paramétrées (instructions préparées). La structure SQL est envoyée séparément des données, de sorte que l'entrée est toujours traitée comme une valeur, jamais comme du code.

Le pilote de base de données associe en toute sécurité les espaces réservés ? aux valeurs fournies.

-- Python (sqlite3 / psycopg)
cur.execute(
  'SELECT * FROM users WHERE name = ? AND pass = ?',
  (username, password)
)

Instructions préparées en Java

Tous les langages courants proposent le paramétrage. En Java, utilisez PreparedStatement plutôt que de construire des chaînes avec Statement.

Les paramètres associés ne peuvent pas sortir de leur emplacement, ce qui rend l'injection structurellement impossible ici.

PreparedStatement ps = conn.prepareStatement(
  "SELECT * FROM users WHERE name = ?");
ps.setString(1, userInput);
ResultSet rs = ps.executeQuery();

Procédures stockées

Les procédures stockées peuvent être utiles lorsqu'elles utilisent en interne des entrées paramétrées. Attention toutefois : une procédure stockée qui construit du SQL dynamique par concaténation est tout aussi vulnérable.

  • Sûr : paramètres transmis à la procédure.
  • Dangereux : EXEC() de chaînes concaténées à l'intérieur de la procédure.

Validation des entrées et listes d'autorisation

La validation constitue une deuxième couche utile. Utilisez des listes d'autorisation (n'acceptez que les modèles connus comme sûrs) plutôt que des listes de blocage (qui tentent d'interdire les caractères dangereux).

Par exemple, un champ d'ID numérique doit rejeter tout ce qui ne contient pas uniquement des chiffres avant même que la valeur n'atteigne la requête.

if not user_id.isdigit():
    raise ValueError('invalid id')
# only then use the value

L'échappement en dernier recours

L'échappement manuel des guillemets est fragile et source d'erreurs. Les différentes bases de données appliquent des règles d'échappement différentes, et des cas particuliers (astuces d'encodage, injection de second ordre) peuvent passer au travers.

Privilégiez les requêtes paramétrées. N'utilisez l'échappement que lorsqu'un ORM ou un pilote ne peut pas paramétrer un identifiant particulier.

Moindre privilège pour les comptes de base de données

Limitez les dégâts d'une injection réussie en appliquant le principe du moindre privilège au compte de base de données utilisé par l'application.

  • Accordez uniquement SELECT, INSERT et UPDATE sur les tables nécessaires.
  • N'utilisez jamais un compte de superutilisateur ou root pour l'application.
  • Refusez DROP, FILE et les droits d'administration.
GRANT SELECT, INSERT, UPDATE ON appdb.orders TO 'webapp'@'%';
REVOKE DROP, ALTER ON appdb.* FROM 'webapp'@'%';

ORM et constructeurs de requêtes

Les outils ORM modernes (Hibernate, Sequelize, Django ORM, SQLAlchemy) paramètrent les requêtes par défaut, ce qui élimine la majeure partie du risque d'injection.

Le danger réapparaît lorsque les développeurs utilisent du SQL brut ou une interpolation de chaînes dans un constructeur de requêtes. Transmettez toujours les valeurs comme paramètres associés, même en mode brut.

Défense en profondeur

Aucun contrôle isolé ne suffit. Combinez plusieurs couches :

  • Requêtes paramétrées partout (défense principale).
  • Validation des entrées et listes d'autorisation.
  • Comptes de base de données appliquant le moindre privilège.
  • Un pare-feu applicatif Web (WAF) pour détecter les modèles connus.
  • Une gestion des erreurs qui ne divulgue jamais de SQL ni de traces de pile.

Vérification rapide

Testez votre compréhension de la défense principale.

Récapitulatif

Vous avez appris comment fonctionne l'injection SQL et comment l'empêcher :

  • SQLi résulte de la concaténation d'entrées non fiables dans les requêtes.
  • Les requêtes paramétrées constituent la principale défense.
  • Ajoutez une validation par liste d'autorisation, des comptes de base de données appliquant le moindre privilège et un WAF.
  • Évitez l'échappement manuel et le SQL dynamique dans les procédures stockées.

La défense en profondeur empêche qu'une seule erreur ne se transforme en compromission.

Questions Fréquemment Posées

La leçon « Défense contre l’injection SQL » est-elle gratuite ?

Oui — le texte complet de « Défense contre l’injection SQL » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Cyber Security Academy, passe à CoddyKit PRO. Le cours Cyber Security Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Défense contre l’injection SQL » ?

Prévenir les attaques par injection Tu pratiques Cyber Security Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Cyber Security Academy ?

Aucune expérience préalable n'est requise. Cyber Security Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.

Combien de temps prend la leçon « Défense contre l’injection SQL » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Cyber Security Academy ?

Oui. Chaque leçon Cyber Security Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Défense contre l’injection SQL
  2. Contrôle d’accès et chiffrement
  3. Audit et surveillance
  4. Sécurité des sauvegardes et de la récupération
← Retour à Cyber Security Academy