L'injection SQL est une des failles les plus prisées. Nous ne comptons plus petites et grandes organisations ayant vu des données sensibles aspirées avec tous les impacts qui en découlent [DBLOSS]. Malheureusement, cela ne témoigne pas d'une grande technicité de l'exploitation, mais plutôt d'erreurs classiques d'implémentation logicielle. Cet article expose les recommandations à mettre en œuvre pour une défense adéquate dans la prévention des injections SQL.
1. Introduction
L'injection SQL est définie par [CWE89] de la manière suivante : « The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. ». En effet, l'injection SQL est une classe de vulnérabilité consistant à détourner des requêtes SQL légitimes via une injection de code SQL qui sera alors interprétée et exécutée par la base de données.
Plus généralement, comme toute faille liée à l'injection, il s'agit d'essayer de mélanger des données avec du code. Dans le cas de l'injection SQL, les données seront issues d'informations non de confiance comme des entrées issues d'utilisateurs de manière directe (e.g. depuis le Web) ou indirecte (e.g. depuis une autre base de données) ; et seront alors utilisées dans…
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première