Comment puis-je éviter les attaques par injection SQL dans mon ASP.NET application?

J'ai besoin pour éviter d'être vulnérable à une injection SQL dans mon ASP.NET application. Comment pourrais-je accomplir?

OriginalL'auteur balaweblog | 2008-11-20

  1. 20

    Même si votre question est très générique, quelques règles s'appliquent toujours:

    • Utiliser des requêtes paramétrées (SqlCommand avec SqlParameter) et mettre de la saisie de l'utilisateur dans les paramètres.
    • De ne pas construire des chaînes SQL de décoché la saisie de l'utilisateur.
    • Ne présumez pas que vous pouvez construire une désinfection de routine qui permet de vérifier la saisie de l'utilisateur pour chaque type de malformedness. Les cas limites sont facilement oubliés. Vérification de l'entrée numérique peut être assez simple pour vous mettre sur le côté sûr, mais pour l'entrée de chaîne juste utiliser des paramètres.
    • Vérifier deuxième niveau de vulnérabilités - ne pas construire des chaînes de requête SQL de SQL valeurs de la table si ces valeurs se composent d'une entrée utilisateur.
    • Utiliser des procédures stockées pour encapsuler les opérations de base de données.
    Tous ceux qui, à l'exception peut-être la dernière, sont sous-entendus par le premier (si tous vos commentaires sont échappées, toujours, par l'utilisation des requêtes préparées (ou des requêtes paramétrées)), non? Ou si vous pensez qu'il y a de subtiles différences?
    Pas de. Mais quelqu'un qui pose ce genre de questions très probablement n'a pas de comprendre les implications. Rendre explicites est de soutenir la compréhension. Comme votre expérience et les aptitudes à l'abstraction lieu, vous n'aurez pas besoin de la précision, et vous n'êtes pas susceptible de poser de telles questions plus.
    C'est une bonne réponse, mais j'ai l'impression que "l'Utilisation des procédures stockées pour encapsuler les opérations de base de données" est trompeur. Paramétrable SQL dynamique est tout aussi sûre que paramétrable des procédures stockées. Peut-être que vous devriez faire que de plus en plus implicite dans votre réponse pour une question de clarté.
    Paramètre des requêtes comme il est utilisé avec SqlCommand, doivent être utilisés si le développeur n'a pas beaucoup de contrôle ou d'expertise dans la base de données de trucs techniques. Création de procédures stockées dans la base de données n'est pas simple si vous êtes un simple développeur C# et non DBA. L'utilisation de procédures stockées est une bonne façon de le faire si le DBA(s) veut le faire, afin d'intégrer la complexité pour les développeurs C#.
    Je suis d'accord. La réponse pourrait être amélioré par la diviser en 2 parties: d'Abord les points 2 à 4 de réponse à ce dont vous avez besoin à considérer, et puis les points 1 et 5 du possible, des solutions sur la façon de résoudre les problèmes mis en évidence.

    OriginalL'auteur Tomalak

  2. 16

    Utilisation Les Requêtes Préparées (lien à un ASP.NET tutoriel qui utilise les requêtes préparées dans la "Pour ajouter des nœuds pour les produits" de la section). c'est tout là est à lui.

    Bien, ou utiliser un ORM, comme Linq to SQL ou NHibernate, ils en interne l'utilisation des requêtes préparées.

    OriginalL'auteur Vinko Vrsalovic

  3. 11

    Utiliser des paramètres! C'est vraiment simple 🙂

    Créer vos requêtes comme ceci (pour MS Sql server avec C#):

    SqlCommand getPersons = new SqlCommand("SELECT * FROM Table WHERE Name = @Name", conn);

    Ici @Nom est le paramètre lorsque vous voulez éviter l'injection sql et conn est un objet SqlConnection.
    Puis ajouter la valeur du paramètre de la manière suivante:

    getPersons.Parameters.AddWithValue("@Name", theName);

    Ici son nom est une variable qui contient le nom que vous recherchez.

    Maintenant, il devrait être impossible de faire des injections sql sur cette requête.

    Puisque c'est ce simple il n'y a aucune raison de ne pas utiliser des paramètres.

    +1 pour une bonne réponse et spécifiques, par exemple.

    OriginalL'auteur Rune Grimstad

  4. 11

    Never trust user input - Valider toutes les entrées de zone de texte à l'aide de contrôles de validation, les expressions régulières, le code, et ainsi de suite

    Ne jamais utiliser le SQL dynamique - Utilisation paramétrée SQL ou des procédures stockées

    Ne jamais se connecter à une base de données à l'aide d'un administrateur de compte au niveau - Utiliser un accès limité compte pour se connecter à la base de données

    Ne pas stocker des secrets en texte brut - Chiffrement et de hachage des mots de passe et autres données sensibles; vous devez également chiffrer les chaînes de connexion

    Exceptions doivent divulguer les informations minimales - Ne pas révéler trop d'informations dans les messages d'erreur; l'utilisation customErrors pour afficher un minimum d'informations en cas d'erreur non gérée; set de débogage pour faux

    Lien utile sur MSDN Arrêt de l'Injection SQL

    Bonne réponse, mais, je suis en désaccord avec "ne Jamais utiliser le SQL dynamique". Le SQL dynamique est un terme très générique et peut être très puissant et il existe de nombreux cas où il doit être utilisé. Votre point faut juste faire passer les données de la variable en tant que paramètres.
    Aye Robin, je suis d'accord SQL Dynamique peut être très utile et il y a quelques cas où il doit être utilisé, par mes points où basée uniquement sur l'interaction avec l'utilisateur dans le monde extérieur, pour arrêter l'injection SQL. Par exemple, les instructions SQL construit par la concaténation de SQL avec des valeurs entrées par l'utilisateur.
    hmm je viens de recevoir -1 vote ainsi qu'un certain nombre de postes en dessous de me cogner à nous tous? (tous par le même utilisateur, peut-être??)
    +1 pour l'utilisation d'un compte limité ligne

    OriginalL'auteur kevchadders

  5. 4

    SQL injection se produit parce que la requête à la base de données est en cours de construction en temps réel, par exemple:

    SELECT * From Table1 WHERE " + UserInput

    UserInput peut être malveillant et contenir d'autres instructions que vous n'avez pas l'intention.

    Pour éviter cela, vous devez éviter de la concaténation de votre requête.

    Vous pouvez accomplir cela en utilisant des requêtes paramétrées - découvrez le DBCommand objet de votre DB saveur.

    OriginalL'auteur Brian Schmitt

  6. 3

    Utiliser des requêtes paramétrées et/ou des procédures stockées et analyser vos paramètres via les paramètres SQL. Jamais générer du code SQL par concaténation de chaînes. Aussi faire un peu de lecture à propos de l'injection SQL et sur l'écriture de code sécurisé, parce que la prévention de l'injection SQL est seulement une petite partie de la sécurité. Il y a beaucoup d'autres (comme XSS (Cross Site Scripting). Si un pirate veut compromettre votre site/application, il va chercher plus alors seulement l'injection SQL.

    OriginalL'auteur Gertjan

  7. 3

    Scott Guthrie posté un peu décent de l'article sur ce dos pendant une. En cela, il dispose de 5 suggestions pour vous protéger:

    1. Ne pas construire des Instructions SQL dynamiques sans l'aide d'un type-safe paramètre mécanisme de codage. [...]

    2. Toujours procéder à un examen de la sécurité de votre application avant de la mettre en production, et d'établir un officiel de la sécurité du processus de revoir tout le code, n'importe quand vous faites des mises à jour. [...]

    3. Ne jamais stocker des données sensibles en clair dans une base de données. [...]

    4. Vous assurer d'écrire l'automatisation des tests unitaires spécifiquement de vérifier votre couche d'accès aux données et les applications contre les attaques par Injection SQL. [...]

    5. Verrouiller votre base de données à n'accorder de l'application web accédant à l'ensemble minimal des autorisations dont il a besoin pour fonctionner. [...]

    Il fait un travail décent de l'expliquer pourquoi elles sont importantes, et des liens vers d'autres ressources ainsi...

    OriginalL'auteur Max

  8. 2

    Ne faites JAMAIS confiance à la saisie de l'utilisateur, toujours la valider et utiliser les paramètres sql. Devrait être suffisant pour éviter l'injection SQL.

    OriginalL'auteur James

  9. 1

    Nous espérons que cela vous aidera:

    http://www.codersbarn.com/post/2008/11/01/ASPNET-Data-Input-Validation.aspx

    La réponse courte est d'utiliser des requêtes paramétrées.

    Anthony 🙂
    http://www.codersbarn.com

    OriginalL'auteur IrishChieftain

  10. 1

    Toujours utiliser uniquement des requêtes paramétrées.

    OriginalL'auteur Eric J.

  11. 0

    Le livre, "Bâtiment Sécurisé ASP.NET les Applications de la ligne directrice" a une section sur ce sujet.

    OriginalL'auteur JohannesH

  12. 0

    Comme d'autres l'ont dit, il ne faut pas concaténer la saisie de l'utilisateur pour créer des instructions sql dynamiques; toujours utiliser SQL paramétrée lors de l'utilisation de SQL dynamique. Cependant je ferai remarquer que cette règle s'applique également lors de la création de sql dynamique à l'intérieur d'une procédure stockée. Ce fait est quelque chose que les gens oublient souvent. Ils pensent qu'ils sont sûrs parce qu'ils sont "à l'aide de procédures stockées."

    OriginalL'auteur Daniel Auger

  13. 0

    Utilisation XSS Sécurisé UrlEncode à l'aide de Microsoft.De sécurité.Application.Anti-xss.UrlEncode et de l'injection SQL ne fonctionne pas. Ou Vous pouvez utiliser ASP.NET – JSON – la Sérialisation et la Désérialisation

    Également tester votre application avec SiteDigger de Macfee Fre Outil.

    Quelques autres sont de ici

    .NET Security Toolkit v1.0
    .NETMon v1.0
    Validator.NET v1.0

    OriginalL'auteur Sashi

  14. 0

    Tout le monde dit "Utiliser les paramètres". Nous aurions-à-dire moins si elle n'était pas si paradoxalement difficile.

    Utilisation QueryFirst. La tentation de concaténer est supprimé, et le droit devient le moyen le plus facile. Vous créez un paramètre juste en tapant @myParam dans votre SQL, l'outil fait le reste.

    avertissement: j'ai écrit QueryFirst

    OriginalL'auteur bbsimonbb

  15. -3

    Comprendre exactement ce que l'Injection SQL est et de ne jamais écrire quoi que ce soit qui est vulnérable.

    OriginalL'auteur Robin Day

  16. -4

    Essayez d'utiliser des Procédures Stockées, et validez la saisie de vos données. Ne pas utiliser de SQL directe comme INSERT INTO ...

    Procédures stockées n'ont rien à faire avec elle, vous pouvez exécuter un SP de façon non sécurisée par pas le paramétrage de l'appel.

    OriginalL'auteur MysticSlayer