Puis-je éviter toutes les attaques d'injection SQL en utilisant des paramètres?
Et ne vous inquiétez de rien dans l'injection SQL dans ce cas?
Ou existe-t-il des types de ces attaques qui nécessitent plus de soins de la part du programmeur?
6 Réponses :
Non, vous ne pouvez pas éviter toutes les attaques d'injection SQL en utilisant des paramètres. Dynamic SQL est le problème réel, ce qui peut se produire dans les procédures stockées ainsi que dans votre code d'application.
E.g., Ceci est sujette à une attaque d'injection SQL: votre requête paramétrée passe un nom d'utilisateur à une procédure stockée et dans la procédure stockée, le paramètre est concaténé à une commande SQL puis exécutée.
Pour un exemple de nombreux types d'attaques d'injection SQL, voir cette Feuille de triche d'injection SQL . Vous verrez que vous allez simplement échapper à des guillemets simples ne fait que gratter la surface et qu'il existe de nombreuses façons.
La solution consiste à ne jamais utiliser SQL dynamique. Si cela n'est pas possible, vous devez vous rendre à des longueurs extrêmes pour vous assurer que vous échappez correctement à une chaîne concaténée à une instruction SQL et à déterminer la manière dont la chaîne est devenue marralé dans des domaines (par exemple, HTML -> JavaScript - -> codage d'URL ->), comme il peut y avoir des complications supplémentaires en raison de ces transformations.
@Quandaire: Ce n'est pas suffisant. Il y a des cas, tels que lorsque vous concatéez un entier, où il n'y aura pas de citations autour de lui. C'est un problème non trivial, et c'est pourquoi il existe pourquoi les requêtes paramétrées existent. Ils résolvent 99% des cas.
Voir le lien que j'ai ajouté à ma réponse qui démontre des attaques d'injection qui n'utilisent pas de guillemets simples et ne seraient donc pas atténuées contre, par remplacement naïf des citations.
Remplacer (Remplacer (Remplacer (Remplacer (@ Yontring, 'Mettre à jour', ''), 'Supprimer', ''), ''), 'Insérez ""), "DROP",' '), ... < / Code> Et ainsi de suite pour chaque action néfaste possible, vous pouvez penser. En d'autres termes, il n'y a pas de solution réelle pour protéger SQL dynamique.
Vous pouvez utiliser des paramètres avec SQL dynamique ... donc cela revient toujours toujours à l'utilisation de paramètres.
@DotJoe: Utiliser des paramètres n'est pas suffisant. C'est comment ils sont utilisés qui est la clé. Il y a un monde de différence entre Set @sql = 'Sélectionnez ... où id = @ ID' et SET @SQL = 'Sélectionnez ... où id =' + @ID <+ @ID / code>
Eh bien, votre deuxième exemple n'est pas en utilisant les paramètres . C'est juste une concaténation de chaînes.
Mon exemple utilise des paramètres pour les deux cas. Le premier exemple utilise un paramètre d'entrée (bien que non défini dans l'échantillon, pour une brièveté) en tant que paramètre intégré; La seconde utilise un paramètre d'entrée en tant que paramètre concaténé. Mon point est de montrer que l'utilisation de paramètres ne suffit pas, vous devez comprendre les détails. Si vous êtes un code d'écriture de développeur utilisant des procédures stockées écrits par quelqu'un d'autre, simplement parce que vous avez utilisé des paramètres pour réussir les données aux procédures stockées ne signifie pas que l'application est à l'abri de l'injection SQL.
Paramètres <> variables. Je suppose que, pour moi, les paramètres dans SQL World signifie toujours Paramètre d'entrée (si c'est ce que cela serait appelé). Si j'appelle la procédure stockée de quelqu'un avec les paramètres, je suis d'accord là-bas n'est pas un moyen de dire si elles utilisent correctement le paramètre sans regarder le SQL.
Si vous allez construire une requête SQL dynamique avec ces paramètres (passés à une procédure stockée, par exemple), il y a une chance d'injection SQL si des précautions ne sont pas prises.
oui et non. Oui, si toutes vos instructions SQL sont en effet statiques et que vous utilisez uniquement des paramètres, vous êtes donc 100% protégé des attaques d'injection SQL.
Le problème vient lorsque les paramètres eux-mêmes sont utilisés pour construire des relevés SQL dynamiques. Un exemple serait une procédure stockée qui génère une instruction SQL de manière dynamique pour interroger une multitude d'options différentes, où une seule déclaration monolithique serait irréalisable. Bien qu'il existe de meilleures solutions à ce problème, ceci est commun.
100%, c'est-à-dire en supposant que MS ou Novell ne produisent aucune erreur.
Vous pouvez toujours minimiser le risque d'injection SQL en utilisant des énoncés préparés, à condition que votre moteur de base de données les prend en charge.
Quoi qu'il en soit, des déclarations préparées sont probablement la manière la plus sécurisée de bloquer les injections SQL.
Oui, vous pouvez éviter toutes les attaques d'injection SQL en utilisant des paramètres, à condition que vous utilisiez des paramètres exclusivement tout en bas de la pile d'appel . Par exemple:
Si vous programmez dans SQL Server, vous pouvez utiliser
sp_executeql < / code> pour exécuter SQL dynamique, et il vous permettra de définir et de passer des valeurs paramétrées à l'instruction exécutée.
+1 Je pense que les gens oublient que vous pouvez utiliser des paramètres avec SQL dynamique.
Le problème consiste à construire la déclaration SQL de manière dynamique.
Par exemple, vous pouvez commander le résultat en fonction de la colonne sélectionnée. Dans la plupart des bases de données, vous ne pouvez pas utiliser les paramètres ici («Commander par?» Ne fonctionne pas). Vous devez donc "commander par" + colonne. Maintenant, si "colonne" est une chaîne, l'utilisateur de votre application Web pourrait l'injecter du code (ce qui n'est pas facile, mais possible).