Les injections SQL

Toutes les entreprises sont aujourd'hui sensibilisées aux problématiques de sécurité de leur extranet. Certaines restent néanmoins insuffisamment informées sur les méthodes utilisées par les pirates. Que le site Web soit conçu par un développement spécifique ou par l'utilisation d'un CMS, les attaques malfaisantes doivent être connues des responsables de la sécurité. Un client m'a contacté récemment parce que la vitrine de son entreprise, son site Web, a été altérée. La mission a démontré que la sécurité n'était pas prise en compte dans les développements.

Sécurité réseau.

Il ne suffit pas de positionner des éléments de sécurité réseau pour être complètement étanche à toute attaque de pirates.
Installer un antivirus et un pare-feu devant un site Web est nécessaire, mais cela reste inefficace pour protéger le SI des faiblesses internes de ce site.

Sécurité logicielle.

Le développement d’applications serveur pour le Web nécessite l'apprentissage des bonnes pratiques de programmation. Elles ont pour but de minimiser les bugs et incitent fortement à tester les données reçues.

Considérons une page d’authentification avec deux champs, login et password.
Le code serveur permettant de vérifier l’identité et le mot de passe est une requête SQL qui ressemble à :

request = “SELECT * FROM members WHERE ident=‘” + login + “' AND pwd=‘” + password + “‘”;

Si l’utilisateur saisit talbain comme login et admin123 comme mot de passe, la requête serveur devient :

request = “SELECT * FROM members WHERE ident=‘talbain' AND pwd=‘admin123‘”;

Or si l’utilisateur est un pirate, il pourra entrer sur le site sans connaitre d’identifiant valide, en saisissant dans le champ login :

‘ OR 1=1 –

La requête devient alors :

requete = “SELECT * FROM members WHERE ident=‘‘ OR 1=1 --' AND pwd=‘‘”;

La requête est toujours vraie et cela permet au pirate d'entrer sur le site.
Mais ce n'est tout, le compte retourné par la requête est le premier enregistrement dans la base de données, ce qui correspond, dans la grande majorité des cas à un compte administrateur.
Remarque : le texte de la requête après les – est ignoré et vu comme du commentaire par les SGBD.

Conclusion

Cet exemple a pour intention de sensibiliser les développeurs à l’importance des tests des valeurs reçues avant de les envoyer dans une requête SQL. Il existe d'autres exemples où le résultat est beaucoup plus dévastateur que celui décrit dans ce billet.
Les dernières bonnes pratiques de développement incitent à développer en plusieurs couches, au moins 5, pour séparer le code métier des données et des IHM. Chaque couche logicielle doit faire l’objet d’un test rigoureux des données reçues avant d’être envoyées dans la couche adjacente.