Je sais que je dois utiliser autant que possible les procédures stockées, mais j'aimerais connaître ce qui suit s'il vous plaît.
A: puis-je obtenir une attaque d'injection SQL à partir d'une instruction SELECT, telle que (SELECT * de MyTable)?
7 Réponses :
Vous pouvez obtenir une attaque d'injection SQL à tout moment que vous n'utilisez pas les requêtes paramétrées, pour la plupart.
Si votre exemple, P>
SELECT * from MyTable WHERE name='x'
Plus précisément, vous pouvez obtenir une injection SQL à tout moment, vous interpolez le contenu non approuvé dans une chaîne de requête et l'exécuter comme SQL dynamique. Vous ne pouvez pas utiliser de paramètres de requête pour les noms de table, les noms de colonne, les mots-clés SQL, les expressions, etc., même si vous utilisez des paramètres, vous pouvez toujours créer des requêtes dangereuses.
Si vous n'utilisez pas de requêtes paramétrées, mais vous pouvez concaténer que vous pouvez obtenir une injection SQL pour tout type de sélection, de mise à jour, de suppression ou d'insertion
Pour répondre à vos questions.
A: Oui, vous pouvez obtenir une attaque d'injection SQL de toute requête On m'a demandé de fournir un exemple de la manière dont une injection peut être faite même en utilisant la procédure stockée. J'ai vu des applications développées qui utilisent des procédures stockées, mais de cette manière: évidemment, ce n'est pas le moyen d'appeler une procédure stockée. Vous devez utiliser les abstractions de votre plate-forme ou les requêtes paramétrées de votre plate-forme. b: Afin d'éviter l'injection, soit:
sqldatasource est une couche d'abstraction pour votre base de données. Il va créer les requêtes SQL pour vous et les assainir automatiquement afin d'éviter toute injection.
Pouvez-vous donner un exemple de la façon dont quelqu'un ferait une attaque d'injection sur une procédure stockée? Merci.
@Steve: Un exemple a été fourni.
Ah, ça a du sens. Merci encore.
Est-il possible d'obtenir une attaque d'injection SQL de toute requête? Par exemple, Sélectionnez * à partir de MyTable . Où se produit l'injection dans ce cas? Aucune concaténation de chaînes ou de variables externes n'est introduite.
@El Ronnoco: Comme aucune autre variables n'est concaténée à la requête, il ne serait pas possible de faire une attaque d'injection SQL sur cette requête.
Injection SQL nécessite que la chaîne SQL soit combinée avec certains paramètres contrôlés par l'utilisateur, de sorte que si l'instruction SELECT est constante, elle est à l'abri des injections. D'autre part, si vous ajoutez un "où user_id =" + useridstring, alors l'injection est possible.
Éviter les injections ne nécessite pas de procédures stockées et que vous ne devriez pas compter sur l'assainissement de vos intrants. Au lieu de cela, il suffit de se lier aux paramètres au lieu de manipuler des chaînes.
Jetez un oeil à: http: // msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlparameter.aspx
Les hacks d'injection se produisent lorsque vous donnez à l'utilisateur la possibilité de manipuler la requête, et avec les requêtes paramétrées la plupart (sinon toutes) les menaces sont neutralisées, car des caractères spéciaux sont échappés pour ne faire que la requête que vous avez souhaitée
Exemple: de
Boîte de recherche: [] [GO] P>
select * from myTable where keywords like '%$searchTerm%'
Chaque fois que vous autorisez un utilisateur à donner des données d'entrée dans une requête SQL dynamique que vous risquez d'injection. Et une sqldatasource ne vous protège pas de l'injection. Inserts, suppressions, gouttes, etc. se produira toujours.
Alors que dois-je faire? Puisque Sqldatasource utilise le paramètre.
En réponse à votre commentaire - 'Que dois-je faire?'
Pour les démarreurs, vous pouvez valider les zones de texte ou quel que soit le contrôle servira à permettre une entrée. Si vous recherchez un numéro, assurez-vous qu'elles ne font que des nombres que si elles entrent un mot, assurez-vous qu'aucune ponctuation n'est disponible. Sortez des personnages comme - et à moins que cela ne soit absolument nécessaire. Vous pouvez faire tout cela avec AJAX et / ou JavaScript. Aussi,
N, vous ne pouvez pas faire cela via JavaScript. Si vous comptez sur JavaScript pour éliminer les caractères potentiellement dangereux, un attaquant peut simplement forger une demande de post HTTP avec tous les "" "dont il a besoin. Cette validation doit arriver le côté serveur. Aussi "Jeter tout" "à moins que l'absollie n'a besoin que j'ai aussi quelque chose que je me donne aussi faux." "Les personnages VALDI sont-ils normaux, la langue humaine et doivent être préservés. L'assainissement doit s'échapper correctement - et son langage ou un cadre de programmation doit fournir un moyen de le faire correctement.
L'utilisation de procédures stockées "autant que possible" ne va pas faire une énorme différence, car la plupart du temps où les gens prennent cette approche, ils concaténent simplement des cordes dans les procédures stockées. L'important est d'utiliser des requêtes paramétrées, des procédures stockées ou non. Ne te tuez pas en essayant de faire tout ce qu'une procédure stockée quand elle ne devrait peut-être pas être une :)
Je suggère de profiter de ce XKCD Comic, une bonne leçon sur l'injection SQL