Chapitre 27. Sécurité des bases de données

Table des matières
Schéma de base de données
Connexions au serveur de base de données
Modèle de stockage avec chiffrement
Injection SQL

De nos jours, les bases de données sont des composants incontournables des serveurs web et des applications en ligne, qui fournissent du contenu dynamique. Des données secrètes ou critiques peuvent être stockées dans les bases de données : il est donc important de les protéger efficacement.

Pour lire ou stocker des informations, vous devez vous connecter au serveur de bases de données, envoyer une requête valide, lire le résultat et refermer la connexion. De nos jours, le langage le plus courant pour ce type de communication est le langage SQL (Structured Query Language). Voyez comment un pirate peut s'introduire dans une requête SQL.

Comme vous pouvez le réaliser, PHP ne peut pas protéger vos bases de données pour vous. La section suivante vous introduira aux notions de base pour protéger vos bases de données, lors de la programmation de vos scripts.

Gardez bien cette règle simple en tête : la défense se fait par couches. Plus vous ajouterez de tests pour protéger votre base, plus faible sera la probabilité de réussite d'un pirate. Ajoutez à cela un bon schéma de base de données, et vous aurez une application réussie.

Schéma de base de données

La première étape est de créer une base de données, à moins que vous ne souhaitiez utiliser une base de données déjà créée. Lorsque la base de données est créée, un utilisateur propriétaire en est responsable. Généralement, seul le propriétaire (et le super utilisateur) peuvent intervenir avec les tables de cette base, et il faut que ce dernier donne des droits à tous les intervenants qui auront à travailler sur cette base.

Les applications ne doivent jamais se connecter au serveur de bases de données sous le nom du propriétaire ou de l'administrateur, car ces utilisateurs ont des droits très importants, et pourront exécuter n'importe quelle requête, comme la modification de tables, l'effacement de lignes ou même encore, la destruction de la base.

Vous pouvez créer différents utilisateurs de bases de données pour chaque aspect de votre application, avec des droits limités aux seules actions planifiées. Il faut alors éviter que le même utilisateur dispose des droits de plusieurs cas d'utilisation. Cela permet que si des intrus obtiennent l'accès à la base avec l'un de ces jeux de droits, ils ne pourront pas affecter toute l'application.

Il est recommandé de ne pas implémenter toute la logique fonctionnelle dans l'application web (c'est-à-dire dans vos scripts), mais d'en reporter une partie dans la base en utilisant les triggers, vues et règles. Si le système évolue, les nouvelles versions vous feront réécrire toute la logique et donc tous vos scripts. De plus, l'utilisation de trigger permet de gérer de manière transparente des données, et fournit des indications pour déboguer votre application.