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, il faut se 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). Voir comment un pirate peut s'introduire dans une requête SQL. Comme on peut s'en douter, PHP ne peut pas protéger les bases de données par lui-même. La section suivante présente les notions de base pour protéger les bases de données, lors de la programmation de scripts PHP. Gardez bien cette règle simple en tête : la défense se fait par couches. Plus il y a de tests pour protéger la base, plus faible sera la probabilité de réussite d'un pirate. En ajoutant à cela un bon schéma de base de données, on obtient une application réussie. La première étape est de créer une base de données, à moins d'utiliser une base de données déjà créée. Lorsque la base de données est créée, elle est assignée à un propriétaire, qui a exécuté l'instruction de création. 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. Il est possible de créer différents utilisateurs de bases de données pour chaque aspect de l'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é. Il est aussi possible d'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 le 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 à la base de données (en contournant le serveur web), les données sensibles, stockées dans la 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 un logiciel de chiffrement propre, et de l'utiliser dans les scripts PHP. PHP peut 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. Voir 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 hachage 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 par un hachage cryptographique. Les fonctions password fournissent une bonne façon de hacher les données sensibles et de travailler avec ces empreintes. 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 hachage stocké en base de données. ]]> L'injection SQL est une technique où un attaquant exploite les failles dans le code d'application responsable de la création de requêtes SQL dynamiques. L'attaquant peut accéder à des sections privilégiées de l'application, récupérer toutes les informations de la base de données, altérer des données existantes, voire exécuter des commandes dangereuses au niveau système sur l'hôte de la base de données. La vulnérabilité se produit lorsque les développeurs concatènent ou interpolent une entrée arbitraire dans leurs déclarations SQL. Dans l'exemple suivant, l'entrée de l'utilisateur est directement interpolée dans la requête SQL, permettant à l'attaquant d'obtenir un compte superutilisateur dans la base de données. ]]> 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. Cependant, il est possible de modifier l'URL en ajoutant une nouvelle valeur, au format URL, comme ceci : Si cela arrive, le script donnerait un accès super utilisateur à l'attaquant. Il est à noter que la valeur 0; fournit un décalage valide à la requête originale et la termine 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 la 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 de stocker uniquement des hachages sécurisés des mots de passe au lieu des mots de passe eux-mêmes 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 : Les instructions UPDATE et INSERT sont également susceptibles à de telles attaques ]]> 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 : ]]> Bien qu'il reste évident qu'un attaquant doit posséder au moins certaines connaissances sur l'architecture de la base de données pour mener une attaque réussie, obtenir ces informations est souvent très simple. Par exemple, le code peut faire partie d'un logiciel open-source et être disponible publiquement. Ces informations peuvent également être divulguées par un code source fermé - même s'il est codé, obscurci ou compilé - et même par le code de l'application à travers l'affichage de messages d'erreur. D'autres méthodes comprennent l'utilisation de noms de table et de colonne typiques. Par exemple, un formulaire de connexion qui utilise une table 'users' avec des noms de colonnes 'id', 'username' et 'password'. Un exemple effrayant de la manière dont des commandes de niveau système d'exploitation peuvent être accessibles sur certains hôtes 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 d'un niveau de droits suffisant, le pirate disposerait désormais d'un compte avec accès au serveur. Certains exemples ci-dessus sont spécifiques à certains serveurs de bases de données, mais cela n'empêche pas des attaques similaires d'être possibles sur d'autres produits. La base de données sera alors vulnérable d'une autre manière. Un exemple amusant concernant l'injection SQL Image de xkcd La méthode recommandée pour éviter les injections SQL est de lier toutes les données via des requêtes préparées. L'utilisation de requêtes paramétrées n'est pas suffisante pour éviter complètement les injections SQL, mais c'est le moyen le plus facile et le plus sûr de fournir une entrée aux instructions SQL. Toutes les valeurs littérales dynamiques dans les clauses WHERE, SET et VALUES doivent être remplacées par des espaces réservés. Les données réelles seront liées pendant l'exécution et envoyées séparément de la commande SQL. La liaison de paramètres ne peut être utilisée que pour les données. Les autres parties dynamiques de la requête SQL doivent être filtrées contre une liste connue de valeurs autorisées. prepare("SELECT * FROM products WHERE id LIKE ? ORDER BY price {$sortingOrder}"); // La valeur est fournie avec des caractères génériques LIKE $stmt->execute(["%{$productId}%"]); ?> ]]> Les instructions préparées sont fournies par PDO, par MySQLi, et par d'autres bibliothèques de bases de données. Les attaques par injection SQL sont principalement basées sur l'exploitation du code qui n'a pas été écrit en tenant compte de la sécurité. Il ne faut jamais faire confiance à une entrée, en particulier côté client, même si elle provient d'une boîte de sélection, d'un champ de saisie masqué ou d'un cookie. Le premier exemple montre qu'une telle requête simple peut causer des désastres. Une stratégie de défense en profondeur implique plusieurs bonnes pratiques de codage : Il ne faut jamais se connecter à la base de données en tant que superutilisateur ou en tant que propriétaire de la base de données. Il convient de toujours utiliser des utilisateurs personnalisés avec des privilèges minimaux. Il faut vérifier si l'entrée donnée a le type de données attendu. PHP a une large gamme de fonctions de validation d'entrée, des plus simples trouvées dans Fonctions de variables et dans Fonctions de type de caractères (par exemple is_numeric, ctype_digit respectivement) et jusqu'à la prise en charge des Expressions régulières compatibles avec Perl. Si l'application s'attend à une entrée numérique, il convient de vérifier les données avec ctype_digit, de changer silencieusement son type en utilisant settype, ou d'utiliser sa représentation numérique avec sprintf. Si la couche de base de données ne prend pas en charge la liaison de variables, alors il faut mettre chaque valeur fournie par l'utilisateur non numérique entre guillemets avec la fonction d'échappement de chaîne spécifique à la base de données (par exemple mysql_real_escape_string, sqlite_escape_string, etc.). Les fonctions génériques comme addslashes ne sont utiles que dans un environnement très spécifique (par exemple MySQL dans un ensemble de caractères à octets uniques avec NO_BACKSLASH_ESCAPES désactivé), il est donc préférable de les éviter. Il est particulièrement important de ne pas divulguer d'informations spécifiques à la base de données, en particulier sur le schéma, que ce soit de manière légale ou illégale. Se référer également à Rapport d'erreurs et Fonctions de gestion et de journalisation des erreurs. À côté de ces conseils, il est recommandé d'enregistrer les requêtes, soit dans les 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 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 il y a de détails, mieux c'est.