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 PHP. 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. 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 puissent pas affecter toute l'application. Il est recommandé d'établir des connexions au serveur avec le protocole SSL, pour chiffrer les échanges clients/serveur, afin d'améliorer la sécurité. Vous pouvez aussi utiliser un client SSH pour chiffrer la connexion entre les clients et le serveur de bases de données. Si l'une de ces deux protections est mise en place, il sera difficile de surveiller votre trafic et de comprendre les informations échangées. Les protocoles SSL/SSH protègent les données qui circulent entre le serveur et le client : SSL/SSH ne protège pas les données une fois dans la base. SSL est un protocole en ligne. Une fois que le pirate a obtenu l'accès direct à votre base de données (en contournant le serveur web), les données sensibles, stockées dans votre base sont accessibles directement, à moins que les données de la base ne soient protégées par la base. Chiffrer les données est une bonne solution pour réduire cette menace, mais très peu de bases de données offrent ce type de chiffrement. Le moyen le plus simple pour contourner ce problème est de créer votre propre logiciel de chiffrement, et de l'utiliser dans vos scripts PHP. PHP peut vous aider dans cette tâche grâce aux nombreuses extensions dont il dispose, comme OpenSSL et Sodium, qui connaissent un large éventail de méthodes de chiffrement. Le script PHP va chiffrer les données qui seront stockées, et les déchiffrer lorsqu'elles seront relues. Voyez la suite pour des exemples d'utilisation de ce chiffrement. Dans le cas de données vraiment sensibles, si la représentation originale n'est pas nécessaire (pour affichage, ou comparaison), utiliser un hash est une bonne solution. L'exemple classique est le stockage de mots de passe dans les bases de données, après les avoir passés au en hachage de cryptage. Les fonctions password fournissent une bonne façon de hacher les données sensibles et fonctionnent avec ces haches. La fonction password_hash est utilisée pour hacher une chaîne donnée en utilisant l'algorithme le plus fort actuellement disponible et la fonction password_verify vérifie si le mot de passe fourni correspond au hash stocké en base de données. ]]> De nombreux développeurs web ne sont pas conscients des possibilités de manipulation des requêtes SQL, et supposent que les requêtes SQL sont des commandes sûres. Cela signifie qu'une requête SQL est capable de contourner les contrôles et vérifications, comme les identifications, et parfois, les requêtes SQL ont accès aux commandes d'administration. L'injection SQL directe est une technique où un pirate modifie une requête SQL existante pour afficher des données cachées, ou pour écraser des valeurs importantes, ou encore exécuter des commandes dangereuses pour la base. Cela se fait lorsque l'application prend les données envoyées par l'internaute, et l'utilise directement pour construire une requête SQL. Les exemples ci-dessous sont basés sur une histoire vraie, malheureusement. Avec le manque de vérification des données de l'internaute et la connexion au serveur avec des droits de super utilisateur, le pirate peut créer des utilisateurs, et créer un autre super utilisateur. ]]> Un utilisateur normal clique sur les boutons 'suivant' et 'précédent', qui sont alors placés dans la variable $offset, encodée dans l'URL. Le script s'attend à ce que la variable $offset soit alors un nombre décimal. Cependant, il est possible de modifier l'URL en ajoutant une nouvelle valeur, au format URL, comme ceci : Si cela arrive, le script va créer un nouveau super utilisateur. Notez que la valeur 0; sert à terminer la requête originale et la terminer correctement. C'est une technique répandue que de forcer l'analyseur SQL à ignorer le reste de la requête, en utilisant les symboles -- pour mettre en commentaires. Un moyen disponible pour accéder aux mots de passe est de contourner la recherche de page. Ce que le pirate doit faire, c'est simplement voir si une variable du formulaire est utilisée dans la requête, et si elle est mal gérée. Ces variables peuvent avoir été configurées dans une page précédente pour être utilisées dans les clauses WHERE, ORDER BY, LIMIT et OFFSET des requêtes SELECT. Si votre base de données supporte les commandes UNION, le pirate peut essayer d'ajouter une requête entière pour lister les mots de passe dans n'importe quelle table. Utiliser la technique des mots de passe chiffrés est fortement recommandé. ]]> La partie statique de la requête, combinée avec une autre requête SELECT, va révéler les mots de passe : ]]> Si cette requête, exploitant les ' et -- est affectée à une variable utilisée dans $query, une injection SQL va se produire. Les commandes UPDATE sont aussi sujettes à des attaques de votre base de données. Ces requêtes peuvent aussi introduire toute une nouvelle requête dans votre commande initiale. Mais en plus, le pirate peut jouer sur la commande SET. Dans ce cas, il doit connaître un peu votre base de données. Cela peut se deviner en examinant les noms de variables dans les formulaires, ou simplement, en testant les cas les plus classiques. Il n'y a pas beaucoup de conventions de noms pour stocker des noms d'utilisateurs et des mots de passe. ]]> Mais un internaute fourbe peut envoyer une valeur telle que ' or uid like'%admin% dans $uid pour modifier le mot de passe utilisateur, ou simplement, utiliser la variable $pwd avec la valeur hehehe', trusted=100, admin='yes pour obtenir des droits supplémentaires. La requête devient alors : ]]> C'est un exemple terrible d'acquisition de droits d'administrateur sur un serveur de base de données. ]]> Si le pirate injecte la valeur a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- dans la variable $prod, alors la requête $query devient : ]]> MSSQL Server exécute les requêtes SQL en lot, y compris la commande d'ajout d'un nouvel utilisateur à la base de données locale. Si cette application fonctionnait en tant que sa et que le service MSSQLSERVER disposait de niveau de droits suffisant, le pirate dispose désormais d'un compte avec accès au serveur. Certains des exemples ci-dessus sont spécifiques à certains serveurs de bases de données. Cela n'empêche pas des attaques similaires d'être possibles sur d'autres produits. Votre base de données sera alors vulnérable d'une autre manière. Un exemple concernant l'injection SQL Image de xkcd Bien qu'il semble évident qu'un pirate doit posséder quelques connaissances de l'architecture de la base de données afin de conduire avec succès une attaque, il est souvent très simple de les obtenir. Par exemple, si la base de données fait partie d'un paquet open source ou disponible publiquement, ces informations sont complètement ouvertes et disponibles. Ces informations peuvent aussi être divulgués pour des codes sources fermés - y compris si ce code est encodé, occulté, ou compilé - aux travers des messages d'erreurs. D'autres méthodes consistent à deviner l'utilisateur de table commune ainsi que des noms des colonnes. Par exemple, un formulaire d'identification qui utilise la table 'users' avec les colonnes de noms 'id', 'username', et 'password'. Ces attaques sont généralement basées sur l'exploitation de code qui n'est pas écrit de manière sécuritaire. N'ayez aucune confiance dans les données qui proviennent de l'utilisateur, même si cela provient d'un menu déroulant, d'un champ caché ou d'un cookie. Le premier exemple montre comment une requête peut causer un désastre. Ne nous connectez jamais sur une base de données en tant que super utilisateur ou propriétaire de la base. Utilisez toujours un utilisateur adapté, avec des droits très limités. Utilisez des requêtes préparées avec des variables liées. Elles sont disponibles avec PDO, MySQLi ainsi que d'autres bibliotèques. Vérifiez que les données ont bien le type attendu. PHP dispose d'un éventail de fonction de validation large, depuis les plus simples, de la section Variables et la section Caractères (e.g. is_numeric, ctype_digit respectivement) aux fonctions avancées de Expression rationnelle Perl. Si l'application attend une entrée numérique, vérifiez vos données avec la fonction ctype_digit, ou bien modifiez automatiquement le type avec la fonction settype, ou encore avec sprintf. ]]> Si la couche de base de données ne suppose pas les variables liées, alors, mettez entre guillemets toutes les valeurs non numériques qui sont passées à la base de données avec la fonction spécifique à la base de données d'échappement de caractères (e.g. mysql_real_escape_string, sqlite_escape_string, etc.). Les fonctions génériques comme addslashes sont utiles uniquement dans un environnement très spécifique (i.e. MySQL avec un jeu de caractères sur un seul octet avec NO_BACKSLASH_ESCAPES désactivé), aussi, il est préférable de ne pas les utiliser. N'affichez jamais d'informations spécifiques à la base, et notamment des informations concernant le schéma. Voyez aussi la section Rapport d'erreur et le chapitre Gestion des erreurs. Vous pouvez avoir des procédures stockées et des curseurs prédéfinis qui font que les utilisateurs n'ont pas un accès direct aux tables ou vues, mais cette solution a d'autres impacts. À côté de ces conseils, il est recommandé d'enregistrer vos requêtes, soit dans vos scripts, soit dans la base elle-même, si elle le supporte. Évidemment, cet enregistrement ne sera pas capable d'empêcher une attaque, mais vous permettra de retrouver la requête qui a fauté. L'historique n'est pas très utile par lui-même, mais au niveau des informations qu'il contient. Plus vous avez de détails, mieux c'est.