Peut instruction paramétrée arrêter tous les injection SQL?

Les liens que j'ai posté dans mes commentaires à la question d'expliquer le problème très bien. Je viens de résumer mes sentiments sur les raisons pour lesquelles le problème persiste, ci-dessous:

1. Ceux qui commencent tout juste peut avoir aucune conscience de l'injection SQL.

2. Certains sont conscients de l'injection SQL, mais pense que l'évitement est la (seule?) solution. Si vous faites une recherche rapide sur Google pour php mysql query, la première page qui s'affiche est le mysql_query page, sur laquelle il y a un exemple qui montre l'interpolation échappé à la saisie de l'utilisateur dans une requête. Il n'y a pas de mention (au moins pas ce que je peux voir) de l'utilisation des requêtes préparées à la place. Comme d'autres l'ont dit, il ya tellement de nombreux tutoriels qui utiliser le paramètre d'interpolation, que ce n'est pas vraiment surprenant de constater que c'est encore souvent utilisé.

3. Un manque de compréhension de la façon dont les instructions paramétrées travail. Certains pensent que c'est juste une fantaisie moyen d'échapper à des valeurs.

4. D'autres sont conscients des instructions paramétrées, mais ne les utilisent pas parce qu'ils ont entendu dire qu'ils sont trop lents. Je soupçonne que beaucoup de gens ont entendu comment incroyablement lent paramterized consolidés sont, mais n'ont pas fait de test de leur propre. Comme le projet de Loi Karwin l'a souligné dans son discours, la différence de performance est rarement utilisé comme un facteur lorsque l'on examine l'utilisation des requêtes préparées. Les avantages de préparer une fois, exécuter de nombreuses, semblent souvent être oublié, de même que les améliorations dans la sécurité et la maintenabilité du code.

5. Certains utilisent des instructions paramétrées partout, mais avec interpolation des valeurs non vérifiées, tels que des tables et des colonnes de noms, mots-clés et les opérateurs conditionnels. Des recherches dynamiques, tels que ceux qui permettent aux utilisateurs de spécifier un certain nombre de différents champs de recherche, de faire une comparaison des conditions et l'ordre de tri, sont d'excellents exemples de cette.

6. Faux sentiment de sécurité lors de l'utilisation d'un ORM. Orm permettent encore d'interpolation de l'instruction SQL pièces - voir 5.

7. De programmation est un sujet vaste et complexe, gestion de base de données est un sujet vaste et complexe, la sécurité est un sujet vaste et complexe. Le développement d'une base de données sécurisée de l'application n'est pas facile - même les développeurs expérimentés peuvent se faire attraper.

8. Beaucoup de réponses sur stackoverflow n'aident pas. Quand les gens écrivent des questions que l'utilisation du SQL dynamique et les paramètres d'interpolation, il y a souvent un manque de réponses qui suggèrent à l'aide des instructions paramétrées à la place. A quelques reprises, j'ai eu des gens de réfuter ma suggestion: utiliser les requêtes préparées, généralement en raison de la perception de l'inacceptable sur les performances système. Je doute sérieusement que ceux qui demandent la plupart de ces questions sont dans une position où le supplément de quelques millisecondes de préparation d'une instruction paramétrée aura un effet catastrophique sur leur application.

Bien bonne question.
La réponse est plus déterministe et stochastique que je vais essayer d'expliquer mon point de vue, à l'aide d'un petit exemple.

Il y a de nombreuses références sur le net qui nous suggérer d'utiliser des paramètres à nos demandes d'information ou d'utiliser une procédure stockée avec des paramètres afin d'éviter l'Injection SQL (SQLi). Je vais vous montrer que des procédures stockées (par exemple) n'est pas la baguette magique contre SQLi. La responsabilité reste encore sur le programmeur.

De considérer les éléments suivants Procédure Stockée SQL Server qui vous permettra d'obtenir la ligne d'utilisateur à partir d'une table "Utilisateurs":

create procedure getUser
 @name varchar(20)
,@pass varchar(20)
as
declare @sql as nvarchar(512)
set @sql = 'select usrID, usrUName, usrFullName, usrRoleID '+
           'from Users '+
           'where usrUName = '''+@name+''' and usrPass = '''+@pass+''''
execute(@sql)

Vous pouvez obtenir les résultats en passant comme paramètres le nom d'utilisateur et le mot de passe. En supposant que le mot de passe en texte libre (seulement pour des raisons de simplicité de cet exemple) d'un appel normal serait:

DECLARE @RC int
DECLARE @name varchar(20)
DECLARE @pass varchar(20)

EXECUTE @RC = [dbo].[getUser] 
   @name = 'admin'
  ,@pass = '!@Th1siSTheP@ssw0rd!!'
GO

Mais ici nous avons une mauvaise technique de programmation utilisé par le programmeur à l'intérieur de la procédure stockée, de sorte qu'un attaquant peut exécuter les opérations suivantes:

DECLARE @RC int
DECLARE @name varchar(20)
DECLARE @pass varchar(20)

EXECUTE @RC = [TestDB].[dbo].[getUser] 
   @name = 'admin'
  ,@pass = 'any'' OR 1=1 --'
GO

Les paramètres ci-dessus seront passées en arguments à la procédure stockée et la commande SQL qui finalement sera exécutée est:

select usrID, usrUName, usrFullName, usrRoleID 
from Users 
where usrUName = 'admin' and usrPass = 'any' OR 1=1 --'

..ce qui permettra d'obtenir toutes les lignes arrière des utilisateurs

Le problème ici est que nous avons tout de même suivre le principe de "Créer une procédure stockée et transmettre les champs de recherche que les paramètres de" la SQLi est toujours pratiquée. C'est parce que nous venons de copier notre mauvaise programmation de la pratique à l'intérieur de la procédure stockée. La solution de ce problème consiste à réécrire notre Procédure Stockée comme suit:

alter procedure getUser
 @name varchar(20)
,@pass varchar(20)
as
select usrID, usrUName, usrFullName, usrRoleID 
from Users 
where usrUName = @name and usrPass = @pass

Ce que j'essaie de dire, c'est que les développeurs doivent apprendre d'abord ce qu'est un SQLi attaque est et comment peut être effectué et pour la sauvegarde de leur code en conséquence. Suivant aveuglément les "meilleures pratiques" n'est pas toujours la manière la plus sécuritaire... et c'est peut-être pourquoi nous avons tant de "bonnes pratiques" - ne!

- Je éviter absolus dans la programmation, il y a toujours une exception. Je recommande fortement les procédures stockées et les objets de commande. La majorité de mon arrière du terrain est avec SQL Server, mais je ne joue qu'avec MySql à partir de temps à autre. Il existe de nombreux avantages pour les procédures stockées, y compris la mise en cache des plans de requête; oui, cela peut être accompli avec des paramètres et dans la ligne de SQL, mais qui ouvre plus de possibilités pour les attaques par injection et n'aide pas à la séparation des préoccupations. Pour moi, il est aussi beaucoup plus facile à sécuriser une base de données que mes applications n'ont généralement autorisation d'exécution de ladite procédures stockées. Sans direct de table/vue de l'accès, il est beaucoup plus difficile à injecter quoi que ce soit. Si les applications de l'utilisateur est compromis, on n'a l'autorisation d'exécuter exactement ce qui a été pré-définis.

Mes deux cents.

Parce que la plupart de code n'est pas écrit en pensant à la sécurité, et la gestion, le choix entre l'ajout de fonctionnalités (en particulier quelque chose de visible, qui peuvent être vendus) et de la sécurité, de la stabilité et de la fiabilité (qui est beaucoup plus difficile de vendre), ils seront presque toujours choisir la première. La sécurité est un sujet de préoccupation seulement quand il devient un problème.

Tout d'abord, ma réponse à votre première question: Oui, autant que je sache, en utilisant des requêtes paramétrées, injections SQL ne sera plus possible. Quant à vos questions ci-dessous, je ne suis pas sûr et ne peut que vous donner mon opinion sur les raisons:

Je pense qu'il est plus facile de "juste" écriture de la chaîne de requête SQL par concaténer les différentes parties (peut-être même dépendant de certains contrôles logiques) ainsi que les valeurs à insérer.
C'est juste de la création de la requête et de l'exécuter.
Un autre avantage est que vous pouvez imprimer (echo, de sortie ou quoi que ce soit) la chaîne de requête sql et ensuite utiliser cette chaîne pour un manuel de requête du moteur de base de données.

Lorsque vous travaillez avec des déclarations préparées à l'avance, vous avez toujours au moins une étape de plus:
Vous devez construire votre requête (y compris les paramètres, bien sûr)
Vous avez à vous préparer à la requête sur le serveur
Vous devez lier les paramètres pour les valeurs réelles que vous souhaitez utiliser pour votre requête
Vous devez exécuter la requête.

Qui est un peu plus de travail (et pas si simple à programmer), en particulier pour certains "rapide et sale" des emplois qui se révèlent souvent être de très longue durée de vie...

Cordialement,

Boîte de

Injection SQL est un sous-ensemble du problème de l'injection de code, où les données et le code sont fournis sur le même canal et de données est pris pour le code. Les requêtes paramétrées empêcher que cela se produise par la formation de la requête à l'aide de contexte sur ce qui est des données et quel est le code.

Dans certains cas précis, ce n'est pas suffisant. Dans de nombreux DBMSes, il est possible d'exécuter dynamiquement SQL avec des procédures stockées, l'introduction d'une faille de SQL injection au SGBD niveau. Appel d'une telle procédure stockée à l'aide de requêtes paramétrées ne va pas empêcher l'injection SQL dans la procédure à partir de l'exploitation. Un autre exemple peut être vu dans ce blog.

Le plus souvent, les développeurs utilisent la fonctionnalité de manière incorrecte. Souvent, le code ressemble à ceci une fois fait correctement:

db.parameterize_query("select foo from bar where baz = '?'", user_input)

Certains développeurs concaténer des chaînes, puis utiliser une requête paramétrée, ce qui n'est pas réellement faire de données ci-dessus/code distinction qui offre les garanties de sécurité que nous recherchons:

db.parameterize_query("select foo from bar where baz = '" + user_input + "'")

La bonne utilisation de requêtes paramétrées offre très fort, mais pas impénétrable, la protection contre les attaques par injection SQL.