L article provient du magazine PHP Solutions. Pour télécharger gratuitement : www.phpsolmag.org La copie et la distribution gratuites de l article sont permisesa condition que sa forme et son contenu original soient conservés.
Tomasz Trejderowski SQL injection Dans la pratique tout site utilisant une base de données peut être sujet aux attaques de type SQL injection. Dans le numéro précédent, nous avons à peine esquissé cette problématique aujourd'hui, nous allons étudier de plus près, bien évidemment sans nous répéter inutilement. Avec PHP Solutions live la configuration permet de tester les problèmes de sécurité décrits dans l'article. Les attaques de type SQL injection ne sont plus celles des débutants plaisantins mais sont devenues les attaques des plus importants pirates internationaux. Le nom provient du terme anglais injection injecter, introduire. Généralement, il s'agit d'erreurs dans les scripts PHP qui transmettent la totalité ou un fragment des données introduites directement par l'utilisateur dans la base. Transmettre ses données sans une analyse préalable, ne serait-ce des plus ordinaires, est une sérieuse erreur cette approche permet à un tiers de modifier les données, de façon à accéder à des informations confidentielles. Systèmes de sécurité perplexes! Les attaques de type SQL injection se produisent entre l'interface (le langage de l'application internet) et les données (le système d'administration de la base de données). Par conséquent, les pro- grammes antivirus ou les firewall ne les gênent pas, étant donné qu'ils opèrent sur le bas niveau. De même, les systèmes de détection des intrus ne parviennent pas non plus à leur faire face IDS (en anglais Intrusion Detection System). Que faut-il savoir? Savoir manipuler le support des bases de données en PHP, Savoir comment sont envoyées les données placées sur la page entre le formulaire et la base de données. Quelles sont nos promesses? Capacité de détecter les erreurs dans les applications conçues par soi-même, Capacité de créer des scripts sécurisés face aux SQL injection. 70 www.phpsolmag.org PHP Solutions N 4/2004
Dans le cas d'attaques de type SQL injection, il n'est pas possible de créer une détection unique des attaques car ces attaques sont conduites en fonction de paramètres propre à chaque cas. Danger négligé Les attaques de type SQL injection sont dangereuses, non du fait de leur nature, mais parce que la majorité des programmeurs internet a peu de connaissances de leur existence, ou bien ne peut pas avoir un regard sur le code du point de vue de l'intrus. Les programmeurs ont du mal à croire que n'importe quel individu qui connaît le login de n'importe quel utilisateur peut se loguer à un site, ou bien même celui qui ne connaît aucun des paramètres du logue! Avant de commencer Avant de passer à la réflexion, abordons encore deux questions qui paraissent tellement évidentes que beaucoup de personnes les oublient tout spontanément. Premièrement, de nombreuses personnes utilisent phpmyadmin pour administrer leurs bases de données. Il faut retenir de ne pas le configurer en mode config. Avec de tels paramètres, tout individu qui devine le chemin d'accès à phpmyadmin (et ce n'est pas un gros problème, étant donné que l'on le place le plus souvent dans le chemin /admin, /phpmyadmin, ou pma) peut visualiser le contenu de nos bases de données. Une telle solution n'est acceptable que quand on teste nos applications sur un serveur local (localhost), cependant sur les serveurs connectés à l'internet, celle-ci est à exclure absolument! Un autre problème est un accès direct aux bases de données. Certains programmeurs, à l'étape de bâtir et tester leur application internet successive, créent des portillons qui permettent une exécution immédiate de la requête à la base, sans la nécessité de recourir à phpmyadmin, ou à la console MySQL démarrée localement. L'exemple d'un tel portillon est présenté sur le Listing 1. Le programmeur crée un simple formulaire qui contient un seul champ texte : <input size="49" name="form_query" value=""> nommé form _ query. L'en-tête adéquatement construite (le marqueur <form>) de ce formulaire fait que sont contenu est dirigé vers le code présenté dans le Listing 1. Ce dernier va exécuter exactement la même requête que celle inscrite dans le champ texte. Cette solution ne peut être employée que pour la durée des test de notre application et seulement, à ce moment là! Si un individu extérieur parvenait à démarrer le script, attention quant à nos données! Cette version du code ne fait pas apparaître les résultats des requêtes envoyées. Mais le seul fait de ne pas être contraint de connaître le login et le mot de passe pour accéder à notre base est très inquiétant. Formulaire de logue dangereux Cet exemple est le moyen plus simple (et à la fois, le plus dangereux) moyen de permettre à l'intrus l'attaque de type SQL injection. Sur la base d'échanges de correspondances avec d'autres programmeurs en PHP, nous sommes en mesure d'affirmer que le moyen présenté (qui permet le intrusions) est utilisé plus souvent que les techniques sécuritaires. Cependant, le moyen exposé pour que l'utilisateur se logue ne permet pas d'attaque de l'intrus, par conséquent, on va le communiquer en tant que recette. Mais avant d'y parvenir, présentons l'essentiel du problème. Regardons le code de l'utilisateur présenté dans le Listing 2. Il sert à loguer l'utilisateur si celui-ci communique un login et un mot de passe corrects. Les variables $login _ form et $pass _ form sont le contenu des champs adéquats du formulaire qui sert à se loguer : l'utilisateur communique dans le formulaire Listing 1. Exemple de portillon pour exécuter immédiatement les requêtes MySQL <?php connect_to_database(); mysql_query($form_query);?> qui lui est alloué, un login et un mot de passe, ensuite, il clique sur le bouton qui envoie les données au code ci-dessus. Par contre, notre script charge de la base de données toutes les lignes pour lesquelles les deux conditions sont remplies à la fois. Puisque la base de données ne peut avoir qu'un seul utilisateur d'un nom donné, communiquer les seuls login et le mot de passe corrects a pour effet de retourner un nombre des lignes autre que 0 et en même temps le démarrage des procédures ultérieures. Admettons à présent, une situation théorique où l'utilisateur inscrit en tant que login et en tant que mot de passe 'mot de passe' or 0=0. Théoriquement, notre script devrait réagir par une négation (dans le code dans le Listing 2, les commandes après else). C'est enfin évident l'utilisateur login n'existe pas dans notre base. Toutefois, c'est faux. Pourquoi? Regardons comment se présente la requête MySQL, envoyée à la base de données avec les paramètres ci-dessus : SELECT * FROM users WHERE login='login' AND pass='mot de passe' or 0=0 Malgré une inexistence réelle d'un tel utilisateur, les deux premières conditions vont retourner FALSE, la troisième condition (0=0) est toujours véridique, donc elle retourne toujours TRUE. En somme, la requête évoquée, envoyée à la base de données MySQL est donc équivalente à la requête : SELECT * FROM users En conséquent, communiquer de tels paramètres va permettre de sélectionner PHP Solutions N 4/2004 www.phpsolmag.org 71
Listing 2. La procédure du logue de l'utilisateur qui rend possible les attaques de type SQL injection <?php $query=mysql_query("select * FROM users WHERE login= login_form AND pass= $pass_form "); $lcount=mysql_num_rows($query); if($lcount!=0) echo 'logué'; //Autres opérations liées au logue de l'utilisateur else echo 'login ou mot de passe incorrects'; //Autres opérations liées aux données communiquées de façon erronée?> Sécurité Figure 1. Schéma illustrant une utilisation non autorisée de données confidentielles par un utilisateur déclaré toutes les lignes du tableau. Il va s'en suivre que la condition qui vérifie si le nombre de lignes sélectionné n'est pas égal à zéro sera remplie et... l'utilisateur sera logué! Quelqu'un pourrait à ce moment là, rétorquer qu'il ne se sent pas concerné par ce problème car dans le cas de son site, le nom est enregistré dans un cookie. Ainsi, l'utilisateur «logué» de cette manière ne pourra utiliser aucune fonction, accessible uniquement aux individus déclarés parce que son nom ne sera jamais trouvé sur le serveur MySQL. En effet, le problème ne se pose pas si l'individu qui tente l'attaque ne connaît pas le login d'un utilisateur donné du site. En revanche, si l'individu en connaît un (et le connaître ne constitue aucun problème : si le site possède un forum, les informations qui y sont publiées, sont signées des noms des utilisateurs) utiliser le code du Listing 2 en tant que procédure de logue, frôle la catastrophe. Puisque l'on peut (avec SQL injection) se loguer au support en tant que n'importe quel utilisateur, sans connaître le mot de passe! Comment y parvenir? Il suffit de fournir comme login, le nom de n'importe quel utilisateur, d'ajouter à la fin ';--, et de laisser le champ du mot de passe vide. Admettons que l'on utiliser le login de l'utilisateur admin, alors, dans le champ login, on inscrit la chaîne admin';--. Dans ce cas, la requête MySQL envoyée dans la base se présenterait ainsi : SELECT * FROM users WHERE login='admin';--' AND pass='' Il se peut que certains perçoivent déjà l'essentiel du problème. Voilà que la chaîne ;-- (le point-virgule et deux moins) fait que la suite de la requête MySQL est ignorée. Le système de bases de données que l'on a utilisé (dans ce cas MySQL) agirait de sorte que la requête se présente de cette manière : SELECT * FROM users WHERE login='admin';-- Donc (conformément à la réalité), en réponse, le système va retourner la ligne du tableau qui contient les données de l'utilisateur correspondant au login que nous avons communiqué. La fonction mysql _ num _ rows($query) qui suit, donne à la variable $lcount, la valeur 1 (le nombre de lignes retourné par la base), ce qui va permettre à nouveau de tromper la ligne qui vérifie le nombre de lignes retourné en réponse et ce qui va loguer les données d'un utilisateur donné. Par conséquent, l'intrus va réussir à se loguer à notre support, en connaissant seul login de l'utilisateur, lequel (certainement, tout à fait par hasard) fut choisi pour être sa victime. Le problème réside dans le fait que cette fois, il s'agira de l'utilisateur existant dans la base de données. Si notre support fait appel aux financements réels (par exemple : le paiement minimum) et que l'on ne recourt pas à une sécurité supplémentaire, l'intrus peut profiter de la section pré-payée du site sur le compte de sa victime. Et ce dernier, sans s'en douter, va se loguer le lendemain, pour constater avec effroie que son compte est... vide! Deux et autres questions Les utilisateurs de base de données de type PostgreSQL et MS-SQL sont confrontés à un problème encore plus important. Or, PHP ne permet pas de placer plus d'une requête dans la chaîne transmise dans la fonction mysql _ query. C'est pourquoi, l'intrus ne peut librement modifier que la requête de base dans ce cas SELECT. Grâce à ça, il n'a que la possibilité d'afficher les informations de la base de données. Toutefois, dans la cas de PostgreSQL (MS-SQL), de telles restrictions n'existent pas. Dans la chaîne transmise dans la fonction pg _ query (mssql _ query), on peut communiquer plus d'une requête. Admettons donc, une autre situation théorique où l'intrus communique en tant que login, la valeur ; delete 72 www.phpsolmag.org PHP Solutions N 4/2004
Sécurité Hélas, une telle méthode peut être contournée mais elle exige un peu plus d'effort. Le diagramme de ce fonctionnement est présenté en tant qu'algorithme sur la Figure 1. Il faut se rendre compte qu'il s'agit aussi d'une attaque de type SQL injection. Bien que nous n'ayons pas changé la syntaxe seule de la requête, nous avons changé un paramètre qui est un élément d'assemblage. De cette façon, nous avons obtenu l'accès à des informations dont nous ne sommes pas destinataires. Et aujourd'hui, à l'époque des vols répandus (hélas) d'identités, l'accès à toutes les données d'un utifrom users--. Le guillemet simple placé au début, va terminer une partie de la requête qui concerne les données introduites de l'extérieur. Le point-virgule qui le suit termine la première requête et commence la suivante (ici : delete from users). Puis le signe de double moins indique dans la requête, le début d'un commentaire, par conséquent, la suite de la requête va être ignorée. Après avoir transformé les données communiquées par l'utilisateur et avoir interprété les caractères spéciaux, on obtient deux requêtes PostgreSQL (MS-SQL) : SELECT * FROM users WHERE login = "; delete from users Le résultat de l'exécution est la suppression de tout le contenu de la table users! Tout comme les utilisateurs de MySQL, le problème ne concerne pas les habitués d'oraclesql car la syntaxe SQL d'oracle n'admet pas l'exécution de plusieurs commande dans une ligne. Formulaire de logue qui résiste à l'intrusion Une question surgit donc, comment prévenir ce type de situations. L'affaire est plus simple qu'on ne le suppose. Avant tout, il ne faut absolument pas envoyer les chaînes communiquées par l'utilisateur en tant qu'éléments d'assemblages de la requête, à la base de données. Chaque paramètre introduit doit être soumis à l'analyse, même la plus simple et il doit être filtré. Au lieu d'envoyer les données tout de suite, on va utiliser la fonction présentée au début de l'article get _ from _ database(), pour lire les valeurs adéquates de la base de données et les comparer aux valeurs communiquées par l'utilisateur. Cette solution est présentée par le Listing 3. La première des méthodes d'intrusion présentées est détectée par le code durant la première vérification. Si l'utilisateur dont le login ($login _ form) n'existe vraiment pas, la fonction (get _ from _ database) donne à la variable $cnt la valeur 0. Toutefois, si l'on inscrivait au nom d'utilisateur, la chaîne 0=0, déjà évoquée, la valeur donnée à la variable $cnt serait égale au nombre d'utilisateurs dans la base de données. Néanmoins, dans tous les cas, la condition qui se trouve dans la ligne suivante ($cnt!=1), va le vérifier, ce qui va afficher le messages d'erreurs et provoquer Listing 3. Utilisateur logué en mode sécuritaire <?php $cnt=get_from_database("users", "where login='$login_form'", "count(id)"); if($cnt!=1) echo 'Cet utilisateur est inconnu!'; exit; $db_pass=get_from_database("users", "where login='$login_form'", "pass"); if($pass_form == $db_pass) echo 'logué'; //Autres opérations liées à l'action de login de l'utilisateur else echo 'mot de passe erroné'; //Autres opérations liées aux données erronées?> la fin de tâche de l'exécution du script. Le code est également complètement insensible à la deuxième méthode d'intrusion (en ajoutant au nom d'utilisateur la chaîne ;--). Si l'on regarde la syntaxe de la fonction get _ from _ database, on remarque que la condition (l'argument $query dans ce cas égal à where login='$login _ form') se trouve dans tous les cas en fin de la requête MySQL. Ainsi l'apparition de la chaîne ;-- n'y change strictement rien. L'intégralité du processus de logue avec le mot de passe est ici vérifié par une comparaison. Donc, si l'intrus ne connaît que le login de l'utilisateur pour lequel il veut se faire passer, celui-ci ne l'aidera en rien. Tant qu'il ne communiquera pas le bon mot de passe Il ne sera pas logué. Attaques de l'intérieur Les tentatives pour obtenir des informations confidentielles peuvent être initées non par un intrus extérieur, mais par un utilisateur déclaré du système. Ce problème va certainement surgir si l'on archive trop d'informations dans des champs cachés du formulaire. Admettons que dans un exemple de site, l'utilisateur puisse cliquer sur le lien «Mon compte». Il s'affiche alors un écran sur lequel se trouvent des boutons renvoyant aux rubriques adéquates concernant l'utilisateur, par exemple, «Informations de base», «Données de téléadresses», «Paiement» etc. Cliquer sur chacun de ces liens fait démarrer un fragment adéquat du code où les informations doivent être obtenue de quelque part, en fonction de l'identifiant d'utilisateur, pour lequel les informations sont à afficher. Vous pouvez enregistrer un tel identifiant dans un cookie, un champ caché de formulaire ou bien le transmettre dans l'url de la page. La dernière des méthodes utilisées est décidément la moins sécurisée. Si un utilisateur malin remarque que pour afficher ses propres informations concernant par exemple le paiement, vous utilisez cette adresse : http: //adres.pl/user_show_billing.php?user_ id=189543, c'est alors sans scrupules qu'il va introduire à la fin d'une telle adresse, l'idendifiant de l'utilisateur dont il veut obtenir les informations. Vous pouvez ainsi transmettre les informations relative à l'identifiant de l'utilisateur en tant que champ caché d'un formulaire, p. ex. : <input type="hidden" name="id" value="189543"> 73 www.phpsolmag.org PHP Solutions N 4/2004
SQL injection lisateur de notre site par un autre utilisateur peut causer à ce dernier, plus d'ennuis que l'intrusion direct dans le système. Terrain d'intervention Il arrive souvent que le programmeur ne prête pas attention aux dangers qui guêtent son application (considérée comme tout prête) lors du transfert du serveur où elle fut testée -localhost vers le serveur internet, accessible en intégralité en Réseau. Chaque fois, avant de publier une application prête, il vous appartient de vérifier deux aspects élémentaires. Premièrement : si le niveau de privilèges n'est pas trop élevé. Pendant la durée des tests et création d'une application, on s'octroie des droits plus larges que ne le demande la réalisation d'une tâche donnée. En publiant, les applications successives, il faut attribuer les privilèges les plus restrictifs possibles à tous les fichiers, utilisateurs, modules et à l'accès à la base de données, avec lesquels l'application fonctionne sans failles. La deuxième question concerne les fichiers temporaires. Combien de fois, vous est-il arrivé d'avoir introduit dans un fichier donné (p. ex. users.php) tellement de modifications que vous aviez décidé, par sécurité, d'en enregistrer une copie en tant que users.php.bak, users.temp, ou bien sous un quelconque autre nom? Si, à présent, vous copiez fortuitement ce fichier avec les autres sur le serveur internet, ce serait inviter gentiment l'intrus à vous rendre visite! Il suffit d'une mauvaise configuration du serveur, pour pouvoir visualiser le contenu de ce fichier. Les fichiers temporaires, ou les versions antérieures des scripts constituent pour les intrus une source précieuse d'informations pour les noms ou mots de passe! Autres moyens de défense Il y a quelques faits dont la prise en compte alliée à et une réactivité adéquate peuvent réduire significativement empêcher les attaques de type SQL injection dans notre application internet. 1) Pour pouvoir construire une requête efficace, l'intrus doit avoir beaucoup de renseignements sur la structure de notre base. Il doit connaître les noms des tables, des champs et d'autres renseignements de ce mysql_pconnect versus mysql_connect Se connecter au serveur MySQL avec la fonction PHP mysql _ pconnect est une très mauvaise habitude car elle surcharge le serveur. Une connexion durable ainsi établie consomme beaucoup plus de ressources du serveur que dans le cas des connexions non durables créées avec la fonction mysql _ connect. type. Pour les reconnaître, il peut construire exprès des requête erronées, pour, après avoir analysé les messages retournés, obtenir les informations concernant la structure de la base de données. 2) Il faut impérativement de vérifier (filtrer, analyser) avec les procédures adéquates et les instructions conditionnelles, toute les sortes de données chargées de l'extérieur. Il ne faut pas admettre la situation où ces données sont transmises directement dans la requête sans un contrôle quelconque. L'exemple d'une telle analyse a été présenté dans le chapitre «Formulaire de logue qui résiste aux intrusions». 3) À chaque étape de construction d'une application, il faut employer le principe des privilèges minimums. Pour résoudre chaque problématique, il faut attribuer à tous les utilisateurs et modules, les privilèges minimaux, indispensables au but donné. Avant de démarrer une application sur un serveur internet, il faut vérifier en plus, tous les privilèges et les réduire au niveau minimal requis. 4) Il faut impérativement créer des groupes d'opérations qui peuvent être démarrés par l'utilisateur en tant que procédures isolées. Si l'utilisateur possède l'accès à une procédure qui affiche le contenu de la base, il faut transporter toutes les opérations susceptibles de modifier la base, dans une autre procédure. Chacune de ces opérations de modification doit posséder des paramètres d'entrée strictement définis et monitorés en permanence conformément au deuxième principe. 5) Si vous profitez d'un système des bases de données qui permet d'exécuter plus d'une requête dans une ligne, utilisez impérativement le monitoring, si dans la requête, il n'y a pas de point-virgule qui clôt la première et débute la seconde requête. Rejetez tous les sigles disposés en dehors du point-virgule, ou bien stoppez l'exécution de la requête contenant le point-virgule ou d'autres sigles-pilotes. 6) N'admettez absolument pas d'exécuter la requête, si par un moyen ou un autre, il y apparaît le sigle (--) qui ignore la partie de la requête qui le suit. 7) Avant de démarrer une application sur un serveur branché au réseau Internet, il faut de vérifier soigneusement, le contenu des dossiers qui composent cette application et que l'on souhaite publier. 8) Partout, où c'est possible, utilisez le codage des informations archivées dans la base. Il est vrai que cela fait résurgir d'autres problèmes. Par exemple, quand l'utilisateur oublie son mot de passe, et que celui-ci est archivé dans la base sous forme de code, il n'est pas possible de le récuperer, seulement de lui en générer un nouveau. Mais malgré ces inconvénients, ça entrave significativement l'accès aux informations complètes d'une application par un tiers. Problèmes déontologiques Les attaques de type SQL injection ne sont pas qu'un problème d'accès à un serveur donné ou de son endommagement. Comme cela a été évoqué le seul chargement d'informations confidentielles concernant les utilisateurs du support peut causer beaucoup de dégâts. Hormis, le vol d'identité, encore peu répandu en France, l'intrus est en mesure d'extraire des informations très pratiques. Même, si de telles pratiques sont prohibées, certains sites où les paiements s'effectuent avec des cartes bancaires gardent leurs informations stratégiques (le numéro, la date d'expiration) dans des bases non sécurisées. Ce n'est pas d'aujourd'hui que l'on sait que les serveurs des gouvernements sont les moins sécurisés et très mal programmés. Les programmeurs qui reçoivent de lucratives commandes gouvernementales s'avèrent être les pires spécialistes de la sécurités. Mais, il en est ainsi quand un pays est dominé par des intérêts personnels... PHP Solutions N 4/2004 www.phpsolmag.org 74