Injection : pourquoi filtrer les données reçues ?

Un champ de recherche, un formulaire de contact, un identifiant dans une adresse de page : chaque fois, votre site reçoit du texte venu de l'extérieur. Tant que ce texte reste une donnée, tout va bien. Le problème commence quand il est traité comme une instruction. C'est le principe de l'injection, une des failles les plus anciennes et les plus fréquentes du web.

Ce qu'est une injection, sans jargon

Imaginez une secrétaire qui recopie mot pour mot le contenu d'un formulaire dans une consigne interne. Si quelqu'un écrit dans la case « nom » une phrase formulée comme un ordre, la consigne change de sens. Un site qui assemble ses requêtes en collant bout à bout du texte reçu fait exactement cela.

Les variantes portent des noms différents selon le système visé : injection en base de données, injection de script dans la page consultée par d'autres visiteurs, injection de commande vers le système d'exploitation, ou détournement d'un champ destiné à l'envoi d'e-mails. Le mécanisme reste le même.

Pourquoi cette faille persiste

• les contrôles sont parfois faits uniquement dans le navigateur, où ils peuvent être contournés sans difficulté ;
• on pense aux formulaires, mais on oublie les autres entrées : adresses de pages, en-têtes de requête, données reçues d'une API partenaire, contenu importé depuis un fichier ;
• une fonction ancienne, écrite avant l'adoption des bonnes pratiques, subsiste dans un coin de l'application ;
• les données venant d'un autre système interne sont considérées comme sûres par principe, alors qu'elles proviennent parfois d'un formulaire public.

Les trois règles qui neutralisent l'injection

Séparer le code des données

Une requête préparée déclare d'abord la structure de l'opération, puis fournit les valeurs à part. La base de données sait alors que ces valeurs sont du texte, jamais des instructions. C'est la mesure la plus efficace, et elle est proposée par tous les langages courants.

Contrôler l'entrée côté serveur

Pour chaque champ, définissez ce qui est acceptable plutôt que ce qui est interdit : type attendu, longueur maximale, format, valeurs autorisées. Cette approche par liste d'autorisation résiste bien mieux qu'une liste de mots interdits, toujours incomplète. Le contrôle dans le navigateur reste utile pour le confort, mais il ne compte pas comme une protection.

Échapper à l'affichage

Un commentaire, un nom ou un message stocké sans danger peut redevenir dangereux au moment où il est réaffiché. L'échappement consiste à transformer les caractères spéciaux pour qu'ils s'affichent comme du texte au lieu d'être interprétés. Cette règle vaut aussi pour les contenus enregistrés il y a longtemps.

Les entrées que l'on oublie

Comment vérifier que c'est bien fait

Demandez à votre prestataire quel mécanisme est utilisé pour les requêtes en base, où se situe la validation des entrées, et comment les contenus sont échappés à l'affichage. Une relecture de code ciblée sur ces points, ou un test d'intrusion, apporte une réponse concrète. NexSecure vérifie ces mécanismes lors d'un audit de sécurité.