Nous avons une autre discussion ici au travail sur l'utilisation de requêtes SQL paramétrées dans notre code. Nous avons deux côtés dans la discussion: moi et quelques autres qui disent que nous devrions toujours utiliser des paramètres pour se protéger contre les injections SQL et les autres gars qui ne pensent pas que c'est nécessaire. Au lieu de cela, ils veulent remplacer les apostrophes simples par deux apostrophes dans toutes les chaînes pour éviter les injections SQL. Nos bases de données exécutent toutes Sql Server 2005 ou 2008 et notre base de code fonctionne sur .NET Framework 2.0.
Laissez-moi vous donner un exemple simple en C #:
Je veux que nous utilisions ceci:
string sql = "SELECT * FROM Users WHERE Name=@name";
SqlCommand getUser = new SqlCommand(sql, connection);
getUser.Parameters.AddWithValue("@name", userName);
//... blabla - do something here, this is safeAlors que les autres gars veulent faire ça:
string sql = "SELECT * FROM Users WHERE Name=" + SafeDBString(name);
SqlCommand getUser = new SqlCommand(sql, connection);
//... blabla - are we safe now?Où la fonction SafeDBString est définie comme suit:
string SafeDBString(string inputValue)
{
return "'" + inputValue.Replace("'", "''") + "'";
}Maintenant, tant que nous utilisons SafeDBString sur toutes les valeurs de chaîne dans nos requêtes, nous devrions être en sécurité. Droite?
Il y a deux raisons d'utiliser la fonction SafeDBString. Premièrement, c'est la façon dont cela a été fait depuis l'âge de pierre, et deuxièmement, il est plus facile de déboguer les instructions SQL puisque vous voyez la requête exacte qui est exécutée sur la base de données.
Donc alors. Ma question est de savoir s'il suffit vraiment d'utiliser la fonction SafeDBString pour éviter les attaques par injection SQL. J'ai essayé de trouver des exemples de code qui enfreignent cette mesure de sécurité, mais je n'en trouve aucun exemple.
Y a-t-il quelqu'un là-bas qui peut briser ça? Comment feriez-vous cela?
EDIT: Pour résumer les réponses à ce jour:
- Personne n'a encore trouvé le moyen de contourner le SafeDBString sur Sql Server 2005 ou 2008. C'est bien, je pense?
- Plusieurs réponses ont souligné que vous bénéficiez d'un gain de performances lors de l'utilisation de requêtes paramétrées. La raison en est que les plans de requête peuvent être réutilisés.
- Nous convenons également que l'utilisation de requêtes paramétrées donne un code plus lisible et plus facile à maintenir
- De plus, il est plus facile de toujours utiliser des paramètres que d'utiliser différentes versions de SafeDBString, des conversions de chaîne en nombre et des conversions de chaîne en date.
- En utilisant des paramètres, vous obtenez une conversion de type automatique, ce qui est particulièrement utile lorsque nous travaillons avec des dates ou des nombres décimaux.
- Et enfin: n'essayez pas de faire de la sécurité vous-même comme l'a écrit JulianR. Les fournisseurs de bases de données consacrent beaucoup de temps et d'argent à la sécurité. Il n'y a aucun moyen de faire mieux et aucune raison pour laquelle nous devrions essayer de faire leur travail.
Donc, même si personne n'a pu briser la sécurité simple de la fonction SafeDBString, j'ai eu beaucoup d'autres bons arguments. Merci!