Les failles d’injection sont très fréquentes, surtout dans le code ancien. On les retrouve souvent dans les requêtes SQL, LDAP, XPath, noSQL, commandes OS, parseurs XML, arguments de programme, etc. Les failles d’Injection sont faciles à découvrir lors d’un audit de code, mais plus difficilement via test. Scanners et Fuzzers aident les attaquants à les trouver.
=> je mettrai plus via des test
Comment empêcher l'injection?
=> je pinaille mais pour la cohérence Injection
Pour les données en entrée, la « whitelist » avec normalisation est recommandée, mais n’est pas une défense complète dans la mesure où de nombreuses applications requièrent des caractères spéciaux, par exemple les zones de texte ou les APIs pour les applications mobiles.
=> pas de S à API
Pour les requêtes dynamiques restantes, vous devriez soigneusement échapper les caractères spéciaux en utilisant la syntaxe d’échappement spécifique à l’interpréteur. Note: Les structures SQL telles que les noms de table, les noms de colonne, et d'autres ne peuvent pas être échappées et les noms de structures venant de l'utilisateur doivent donc être considérés comme dangereux. Ceci est un problème courant dans les logiciels d'aide à l'écriture de rapports.
=> considérés comme dangereuses
Scenario #2: De même, la confiance aveugle d'une application dans les frameworks qu'elle utilise peut faire que ses requêts sont toujours vulnérables (par exemple Hibernate Query Language (HQL)):
=> faire que ses requêtes
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
=> je ne connais pas HQLQuery mais il ne manque pas un bout à la requête ?