|
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 contruire 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.
Exemple 27-3. Exemple d'injection SQL
|
Note : C'est une techinque 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é.
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 connaitre 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.
C'est un exemple terrible d'acquisition de droits d'administrateur sur un serveur de base de données.
Note : 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.
Vous pouvez prétendre que le pirate doit d'abord obtenir des informations sur le schéma de la base de données, dans la plupart des cas d'injections. C'est vrai, mais vous ne saurez jamais comment ni quand ces informations auront filtré, et si cela arrive, votre base de données sera en grand danger. Si vous utilisez une base de données Open Srouce, ou une base qui est du domaine public, ou encore un schéma qui appartient à un système de gestion de contenu ou d'un forum, le pirate peut facilement se procurer une copie du code que vous utilisez. Cela peut être un risque potentiel si la base a été mal conçue.
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.
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 is_numeric(), ou bien modifiez automatiquement le type avec la fonction settype(), ou encore avec sprintf().
Exemple 27-10. Une navigation de fiches plus sécuritaire
|
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_escape_string(), sql_escape_string(), etc.). Si un mécanisme d'échappement spécifique à une base de données n'existe pas, les fonctions addslashes() et str_replace() peuvent être très utiles (en fonction du type de la base de données). Lisez le premier exemple. Comme le montre l'exemple, ajouter des guillemets à la partie statique de la requête n'est pas suffisant, rendant cette requête facilement piratable.
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.
A coté 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. Evidemment, 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.
Précédent | Sommaire | Suivant |
Modèle de stockage avec chiffrement | Niveau supérieur | Rapport d'erreurs |
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:02:20