Le hachage pourrait-il empêcher l'injection SQL?
Sur un coup de tête, j'ai récemment décidé de lancer le premier site Web que j'ai créé sur mon serveur Web local que j'utilise pour le développement. Je pensais que ce serait un excellent environnement pour lancer du SQL pour l'injection car je sais qu'il y a des défauts et le site n'était vraiment destiné qu'à mon propre développement personnel.
Quoi qu'il en soit, pour en venir au fait, après quelques tentatives, le plus loin que j'ai pu obtenir était d'avoir la page renvoyer une erreur avec la déclaration. J'essayais d'accéder à un compte de test spécifique que j'ai créé (si le résultat renvoie plus d'un compte, une erreur est générée, donc je ne m'attendais pas à sélectionner chaque nom d'utilisateur où 1 = 1 fonctionnerait), mais chaque fois que j'obtenais un réponse comme si j'avais entré un mot de passe normal et incorrect. J'ai jeté un coup d'œil au code PHP et il s'avère que je hachais le mot de passe avant la requête, donc l'attaque était hachée avant qu'elle ne puisse faire de mal.
Étant nouveau dans la sécurité Web dans son ensemble et ayant un intérêt pour le développement Web, je me demandais s'il y avait des vulnérabilités avec cette méthode de prévention injection SQL car je m'attends à ne pas avoir réfléchi. Juste pour clarifier, ce n'est pas censé être un "look les gars, j'ai trouvé quelque chose de nouveau" car il y a beaucoup plus d'étincelles plus brillantes dans la sécurité de l'information que moi, qui l'auraient probablement déjà compris, mais j'aimerais savoir pourquoi cela ne convient probablement pas comme mécanisme de sécurité.
Ainsi, le hachage du mot de passe utilisateur avant de le saisir dans la requête est une fonctionnalité de sécurité fortuite pour empêcher l'injection SQL, mais vous ne pouvez pas nécessairement le faire avec toutes les entrées utilisateur. Si je recherche un client par son nom et que j'ai une requête comme
Select * from Customer Where Name like '%userInput%'
Si je définissais userInput comme une version hachée de ce qui était tapé, cela ne fonctionnerait pas correctement même si Name était également haché dans la base de données, cela ne fonctionnerait que pour une requête de recherche exacte. Donc, si j'avais un client avec le nom "Sue" et que je tapais une recherche de "poursuivre", cela ne fonctionnerait pas. Je ne connais pas non plus le nom des clients à moins qu'il n'y ait une correspondance exacte dans ma recherche, ce qui n'est pas pratique.
La façon dont vous voulez empêcher l'injection SQL est de ne pas faire vos requêtes comme ci-dessus, vous voudrez traiter et paramétrer les entrées dans une requête, en supprimant des choses comme = s et d'autres symboles qui n'ont pas de sens dans le contexte de l'entrée . Un bon guide pour empêcher l'injection SQL peut être trouvé ici .
Fondamentalement oui, si vous hachez une entrée (représentée au format Hex ou Base64) avant de la passer à SQL, elle ne peut plus être un vecteur d'attaque SQLi efficace. Il en va de même si vous parseInt l'entrée. Ceux-ci ne prennent tout simplement pas en charge les caractères nécessaires pour un SQLi utile. (à savoir pour sortir de la chaîne entre guillemets)
Cette technique n'a qu'une utilité limitée dans la pratique. c'est-à-dire qu'il ne serait pas compatible avec certaines des célèbres fonctionnalités SQL telles que LIKE, <, >,
ou des recherches d'égalité indexées (= et <> en utilisant l'index)
En guise de remarque, je voudrais souligner que le hachage de mot de passe devrait vraiment être salé . Si ces critères étaient remplis dans votre exemple, je pense que vous n'incluriez plus de hachage dans la clause SQL WHERE.
Ce que vous faites (par inadvertance) fait partie de ce que l'on appelle la "désinfection de votre entrée", qui sont des mesures que chaque application devrait prendre pour réduire les défauts (et donc les vulnérabilités).
Une application doit d'abord s'assurer que l'entrée ne dépasse pas la capacité de l'application à accepter des données. Cela peut signifier une vérification de la longueur de l'entrée ou autrement rejeter des données surdimensionnées.
Ensuite, l'application devrait vérifier l'entrée par rapport à une liste blanche, si possible, pour s'assurer qu'aucune entrée indésirable ne peut entrer dans la logique. Dans certains cas, cela peut signifier que l'entrée ne contient que des caractères alphanumériques valides. Mais parfois, une liste blanche n'a pas de sens pour ce champ de saisie particulier, mais le développeur doit toujours empêcher l'injection, alors ils incorporent une liste noire. La liste noire valide l'entrée ne contient pas de symboles connus pour rendre l'injection possible. L'inconvénient des listes noires est qu'elles ne protègent que contre ce que le développeur sait bloquer. Un exemple pourrait être une liste noire qui arrête un guillemet pour empêcher l'injection SQL; mais le développeur peut ne pas reconnaître lorsque l'entrée passe par une URL encodée qu'un% 27 deviendra un guillemet.
En interne, la demande doit être rédigée de manière défensive pour se prémunir contre diverses formes d'injection. L'utilisation de SQL paramétré (au lieu de construire une requête SQL à l'aide de la concaténation) permet d'éviter l'injection SQL. Mais de nombreux autres endroits où les entrées d'utilisateurs peuvent être vulnérables à différents types d'injection. Les chemins de répertoire peuvent être affectés si un attaquant entre quelque chose comme "..\..\..\..\..\..\windows\cmd.exe" Les requêtes XPath peuvent être injectées pour falsifier des données non autorisées. Et JavaScript peut traverser la base de données pour altérer le navigateur de la victime. D'autres formes de défense incluent la non-révélation des messages d'erreur de diagnostic interne dans la sortie et la journalisation pour aider à identifier les attaquants potentiels.
Ce que votre application a fait est de passer d'abord l'entrée à une routine de hachage, ce qui a le double effet de filtrer les données et de limiter leur longueur avant qu'elles n'arrivent à l'étape SQL. N'oubliez pas que l'entrée de la routine de hachage peut toujours être vulnérable à un débordement de tampon. Que se passe-t-il lorsqu'un attaquant entre un mot de passe de "aaaa[...repeated 1000 times...]aaaa_Evil_Injection_Here"? Votre application doit toujours gérer cela.
Comme beaucoup d'autres apprenants, vous confondez le stockage et le transport . Et pour protéger ces derniers, vous gâtez délibérément les premiers.
Vous devez comprendre que l'injection SQL n'est pas appelée "injection de base de données" pour une raison. Vous n'avez pas à protéger la base de données, le stockage. Tout ce dont vous avez besoin pour protéger est le transport - la requête SQL. Alors que votre stockage devrait être en mesure de stocker les données telles quelles, ou cela n'aura aucune valeur. Si vous avez toujours besoin d'une preuve pour cette déclaration,
- il pourrait y avoir différents clients, qui n'ont aucune idée de votre "protection" maison
- il n'y a pas seulement une comparaison stricte, et pas seulement une comparaison: il y a un tas d'instructions dans lesquelles vos données pourraient être impliquées: arithmétique, recherche de sous-chaîne, diverses conversions, manipulations de chaînes et calculs de toutes sortes
- une base de données est non seulement utilisée pour stocker vos données mais aussi pour les manipuler. Essayez de ordonner vos noms d'utilisateur hachés
- après tout, il faut parfois imprimer les données à partir d'une base de données.
Vous pouvez donc dire que toute mesure de protection qui modifie les données stockées de quelque manière que ce soit est tout simplement fausse. Et votre idée n'est tout simplement pas bien pensée.
Le hachage protège l'injection SQL du champ de mot de passe grâce à l'étape qui recode sa sortie binaire en chaîne.
Cette protection est normalement inutile mais suffit si les hypothèses suivantes sont vraies:
- Votre application ne gère les chaînes nulle part, sauf le nom d'utilisateur et le mot de passe.
- Vous supprimez le nom d'utilisateur de
'et\personnages.
Si l'une ou l'autre de ces affirmations n'est pas vraie ou pourrait l'être à l'avenir, le hachage n'est pas une défense utile. Cela élimine 99,9% des applications Web.