L'utilisation de SqlCommand paramétrée rend-elle mon programme immunisé contre l'injection SQL ?

Question

Je suis conscient que L'injection SQL est plutôt dangereuse . Maintenant, dans mon code C#, je compose des requêtes paramétrées avec SqlCommand classe :

SqlCommand command = ...;
command.CommandText = "SELECT * FROM Jobs WHERE JobId = @JobId;";
command.Parameters.Add("@JobId", SqlDbType.UniqueIdentifier ).Value = actualGuid;
command.ExecuteNonQuery();

Cela rendra-t-il automatiquement mon code immunisé contre l'injection SQL ? Dois-je faire quelque chose de plus ?

Answer 1

Je dirais que pour votre exemple particulier, et probablement canonique, de requêtes paramétrées, oui c'est suffisant.

Cependant, les gens écrivent parfois du code comme celui-ci

cmd.CommandText = string.Format("SELECT * FROM {0} WHERE col = @col;", tableName);
cmd.Parameters.Add("@col", ...);

parce qu'il n'y a tout simplement aucun moyen de passer le nom de la table lui-même en tant que paramètre et le désir de le faire existe parfois - qu'il soit mal guidé ou non. Il semble que l'on oublie souvent que le nom de la table (à moins qu'il ne soit lu à partir d'un ensemble de valeurs statiques/constantes qui ne dérivent pas d'une entrée) permet effectivement une injection SQL.

Answer 2

Selon la note sur cet article de MSDN , "Les caractères spéciaux d'entrée constituent une menace uniquement avec le SQL dynamique et non lors de l'utilisation du SQL paramétré."

Je pense donc que vous êtes à l'abri d'une injection SQL. Il peut y avoir des risques logiques lorsque vous utilisez des identifiants comme les valeurs d'identité dans vos URL, mais c'est une autre histoire.

Answer 3

L'injection SQL dépend principalement de l'exécution de SQL dynamique. En d'autres termes, les instructions SQL construites par la concaténation de SQL avec des valeurs saisies par l'utilisateur.

Pour éviter complètement l'injection SQL,

Se protéger contre les attaques par injection SQL n'est pas très difficile. Les applications qui sont à l'abri des attaques par injection SQL valident et nettoient toutes les entrées utilisateur, n'utilisent jamais de SQL dynamique, s'exécutent en utilisant un compte avec peu de privilèges, hachent ou cryptent leurs secrets et présentent des messages d'erreur qui ne révèlent que peu ou pas d'informations utiles au pirate. En suivant une approche multicouche de la prévention, vous pouvez être sûr que si une défense est contournée, vous serez quand même protégé.

En MSDN

Answer 4

L'utilisation de SqlCommand est une très bonne pratique et tant que vous ne concaténerez pas de chaînes SQL n'importe où (y compris à l'intérieur des procédures stockées que vous appelez - c'est-à-dire éviter le SQL dynamique), vous serez à l'abri des attaques par injection SQL.

Answer 5

Vous n'êtes pas à l'abri d'une injection SQL si vous utilisez du sql dynamique, même si vous le faites passer par des paramètres. Dommage que le serveur SQL n'ait pas une fonction intégrée pour assainir les paramètres.