Comment SQLParameter prévenir l'Injection SQL?

Ce qui se passe exactement dans le contexte qui le rend si SQLParameter empêche SQL Inection attaques dans un .NET requête Paramétrée? C'est juste de l'enlever, tout suspect caractères ou est-il quelque chose de plus?

A quelqu'un là-bas vérifié pour voir ce qui se fait de SQL Server lorsque vous transmettez des entrées malveillantes?

Connexes: Pouvez-vous utiliser un SQLParameter dans le SQL DE la déclaration?

InformationsquelleAutor Abe Miessler | 2011-02-03
  1. 72

    Fondamentalement, lorsque vous effectuez une SQLCommand à l'aide de SQLParameters, les paramètres ne sont jamais directement insérés dans la déclaration. Au lieu de cela, une procédure stockée système appelé sp_executesql est appelé et donné de la chaîne SQL et le tableau de paramètres.

    Lorsque utilisé en tant que tel, les paramètres sont isolés et traités comme des données, au lieu d'avoir à être analysée de la déclaration (et donc éventuellement de le changer), de sorte que les paramètres contiennent ne peut jamais être "exécuté". Il vous suffit de faire une grosse erreur que la valeur du paramètre n'est pas valide d'une certaine façon.

    • Vous bénéficierez également d'une erreur d'essayer d'utiliser des variables dans les endroits où SQL (et TSQL dans ce cas) ne prend pas en charge les variables. C'est à dire: FROM article, d'un seul paramètre pour représenter une liste séparée par des virgules dans un IN clause, etc.
    • Je ne pense pas que cela répond à la question. Vous pouvez appeler une procédure stockée à l'aide de SQLParameter classe, qui passe params de la procédure, mais ne veut pas l'appeler sp_executesql. Ce qui se passe avec les valeurs de ces paramètres dans un concaténées chaîne sql?
    InformationsquelleAutor KeithS
  2. 45

    Un plus facile à comprendre, et plus de réponse générale va comme ceci:

    Imaginer une dynamique de requêtes SQL:

    sqlQuery='SELECT * FROM custTable WHERE User=' + Username + ' AND Pass=' + password

    Une simple injection SQL serait juste de mettre le nom d'utilisateur en tant que ' OR 1=1--

    Cela permettrait effectivement de faire la requête SQL:

    sqlQuery='SELECT * FROM custTable WHERE User='' OR 1=1-- ' AND PASS=' + password

    Cela dit sélectionnez tous les clients, d'où leur nom d'utilisateur est vide ('') ou 1=1, qui est un booléen, soit vrai. Il utilise ensuite -- pour commenter le reste de la requête. Ce qui permettra de d'imprimer la ensemble table client, ou vous permettre de faire ce que vous voulez avec elle.

    Maintenant des requêtes paramétrées le faire différemment, avec un code comme:

    sqlQuery='SELECT * FROM custTable WHERE User=? AND Pass=?'
    parameters.add("User", username)
    parameters.add("Pass", password)

    où nom d'utilisateur et mot de passe sont variables pointant vers les associés d'inscription nom d'utilisateur et mot de passe.

    Maintenant, à ce stade, vous pensez peut-être, cela ne changera rien du tout. Sûrement, vous pouvez toujours juste de la mettre dans le champ nom d'utilisateur, quelque chose comme Personne OU 1=1'--, ce qui fait la requête:

    sqlQuery='SELECT * FROM custTable WHERE User=Nobody OR 1=1'-- AND Pass=?'

    Et cela semble comme un argument valable. Mais, vous avez tort.

    La façon dont les requêtes paramétrées travail, c'est que la requête SQL est envoyé sous la forme d'une requête et de la base de données sait exactement ce que cette requête va le faire, et alors seulement, il insérez le nom d'utilisateur et mots de passe simplement en tant que valeurs. Cela signifie qu'ils ne peuvent pas affecter la requête parce que la base de données, on sait déjà ce que la requête ne pourra le faire. Donc, dans ce cas, il aurait l'air d'un nom d'utilisateur de Nobody OR 1=1'-- et un mot de passe vide, qui doit venir de faux.

    Cette solution n'est pas complète si, et de validation de la saisie aura encore besoin d'être fait, car ce qui n'affecte pas d'autres problèmes, tels que xss les attaques, comme vous avez pu encore mettre du code javascript dans la base de données. Alors si c'est de lire sur une page, il affiche normalement javascript, selon toute validation de sortie. Si vraiment la meilleure chose à faire est de toujours utiliser la validation de l'entrée, mais à l'aide de requêtes paramétrées ou des procédures stockées pour stopper toutes les attaques SQL.

    Source: http://www.lavamunky.com/2011/11/why-parameterized-queries-stop-sql.html

    • Aime la façon dont vous explique 🙂 propre et au point .
    InformationsquelleAutor anaik
  3. 10

    "Paramètre de collections telles que SqlParameterCollection fournir le type de la vérification et de la validation de la longueur. Si vous utilisez une collection de paramètres, d'entrée est traitée comme une valeur littérale, et SQL Server ne pas le traiter comme le code de l'exécutable. Un avantage supplémentaire de l'utilisation d'une collection de paramètres que vous pouvez appliquer le type et la durée des contrôles. Des valeurs en dehors de la plage de déclencher une exception. C'est un bon exemple de la défense en profondeur."

    http://msdn.microsoft.com/en-us/library/ff648339.aspx

    InformationsquelleAutor Dave Brace
  4. 5

    Lors de l'utilisation de requêtes paramétrées, la surface d'attaque est réduit à monkeying autour avec les paramètres.

    Utilisez SqlParameters, mais n'oubliez pas de dépassement de, dépassement de capacité et non validés paramètres. Par exemple, si la méthode est "proc buy_book (@price money)", un utilisateur malveillant de tenter de tromper l'application en cours d'exécution avec @price ensemble de 0.01, ou de tenter d'obtenir la demande de faire quelque chose d'intéressant en soumettant quelque chose qui provoque un dépassement de capacité. Sql Débordements ont tendance à ne pas être intéressant (c'est à dire juste de provoquer des exceptions, vous êtes susceptibles d'être en mesure d'écrire de mémoire adjacentes)

    InformationsquelleAutor MatthewMartin