Suis-je immunisé contre les injections SQL si j'utilise des procédures stockées?

Question

Disons sur la base de données MySQL (si cela compte).

Answer 1

Non, vous ne serez pas complètement en sécurité. Comme d'autres l'ont mentionné, les requêtes paramétrées sont toujours la meilleure solution, peu importe comment vous accédez à la base de données.

C’est un peu une légende urbaine qui dit que vous êtes en sécurité avec Procs. Je pense que la raison pour laquelle les gens sont dans cette illusion est parce que la plupart des gens supposent que vous appelez les procs avec des requêtes paramétrées à partir de votre code. Mais si vous ne le faites pas, si, par exemple, vous faites quelque chose comme ci-dessous, vous êtes grand ouvert:

SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con);
cmd.ExecuteNonQuery();

Parce que vous utilisez du contenu non filtré de l'utilisateur final. Une fois encore, il ne leur reste plus qu'à mettre fin à la ligne (";"), à ajouter leurs commandes dangereuses et à boum - vous êtes fatigué.

(En passant, si vous êtes sur le Web, ne retirez pas le courrier indésirable non filtré de la chaîne de requête du navigateur - cela rend absurdement facile de faire des choses extrêmement mauvaises pour vos données.)

Si vous paramétrez les requêtes, vous êtes beaucoup mieux en forme. Cependant, comme d’autres l’ont déjà mentionné, si votre procédure continue à générer du SQL dynamique et à l’exécuter, il peut toujours y avoir des problèmes.

Je dois noter que je ne suis pas anti-proc. Procs peut être très utile pour résoudre certains problèmes d'accès aux données. Mais les procs ne sont pas des solutions miracles pour les injections SQL.

Answer 2

Vous n'êtes immunisé contre les injections SQL que si vous utilisez systématiquement des requêtes paramétrées. Vous êtes presque immunisé contre les injections SQL si vous utilisez l'échappement correct partout (mais il peut y avoir et a toujours eu des bugs dans les routines d'échappement, donc ce n'est pas aussi infaillible que les paramètres).

Si vous appelez une procédure stockée en ajoutant les arguments par concaténation, je peux toujours ajouter une requête aléatoire à la fin de l'un des champs de saisie - par exemple, si vous avez CALL CheckLogin @username = '$ username', @ password = '$ password', avec les $ -things représentant des variables directement concaténées, rien ne m'empêche de changer la variable $ password en lecture ''; ''; DROP DATABASE; - ".

Évidemment, si vous nettoyez l’entrée au préalable, cela contribue également à empêcher l’injection SQL, mais cela peut éventuellement filtrer les données qui n’auraient pas dû être nettoyées.

Answer 3

Cela dépend de ce que font vos procs stockés. S'ils génèrent dynamiquement du SQL en fonction de leurs paramètres, puis l'exécutent, vous êtes toujours vulnérable. Autrement, vous irez mieux, mais j’hésite à paraître 100% confiant!

Answer 4

Nope. Si vous construisez du SQL qui appelle une procédure stockée, vous êtes toujours une cible.

Vous devriez créer des requêtes paramétrées côté client.

Answer 5

Non, car vous pouvez toujours utiliser D-SQL dans vos procédures stockées ... et valider et restreindre votre saisie est une bonne idée dans tous les cas.

Answer 6

Les procédures stockées ne constituent pas une garantie, car ce qui est réellement vulnérable est tout code dynamique, qui inclut le code dans les procédures stockées et les appels générés de manière dynamique aux procédures stockées.

Les requêtes paramétrées et les procédures stockées appelées avec des paramètres sont invulnérables à l'injection tant qu'elles n'utilisent pas d'entrées arbitraires pour générer du code. Notez qu'il existe une grande quantité de code dynamique qui n'est également pas vulnérable à l'injection (par exemple, les paramètres entiers dans le code dynamique).

Les avantages d’une architecture largement basée sur les procs stockées (je ne suis pas sûr que 100% soit vraiment possible), c’est que l’injection peut même être un peu défendue (mais pas parfaitement) pour le code dynamique côté client car :

Seules les autorisations EXEC sont accordées à tout contexte utilisateur sous lequel l'application se connecte. Par conséquent, toute requête SELECT, INSERT, UPDATE, DELETE échouera simplement. Bien entendu, DROP, etc. ne devrait de toute façon pas être autorisé. Par conséquent, toute injection doit avoir la forme EXEC. Ainsi, seules les opérations que vous avez définies dans votre couche SP seront même disponibles (et non du code SQL arbitraire) contre lesquelles injecter.

Parmi les autres avantages de la définition de vos services de base de données en tant qu’ensemble de procédures stockées (comme toute couche d’abstraction logicielle), citons la possibilité de refactoriser votre base de données sans affecter les applications, la possibilité de mieux comprendre et surveiller les modèles d’utilisation dans les applications. votre base de données avec un profileur et la possibilité d'optimiser de manière sélective au sein de la base de données sans avoir à déployer de nouveaux clients.

Answer 7

De plus, envisagez d'utiliser un accès à la base de données finement détaillé (également appelé contrôle d'accès basé sur un rôle). L'utilisateur principal de votre base de données doit disposer exactement des autorisations nécessaires pour effectuer son travail, et rien d'autre. Vous n'avez pas besoin de créer de nouvelles tables après l'installation? REVOKE cette permission. Ne pas avoir un besoin légitime de fonctionner en tant que sysdba? Alors ne le fais pas! Une injection sournoise demandant à l'utilisateur de "DROP DATABASE" sera bloqué si l'utilisateur n'a pas obtenu cette autorisation. Ensuite, tout ce dont vous avez besoin est de vous inquiéter, ce sont les instructions SELECT qui fuient des données.