Comment puis-je créer en toute sécurité dans les requêtes ADO.NET où les tables étant choisis parmi le changement?

Question

Dans ADO.NET, vous pouvez ajouter des paramètres à un objet de commande pour ajouter en toute sécurité l'entrée d'utilisateur à une requête SQL. Quel est l'équivalent pour les autres prédicats communs à une requête SQL?

Je suis en train d'écrire un programme qui est essentiellement un O-R mappeur très limité et générateur SQL (il est fortement concentré autour d'une base de données avec des méta-informations et d'autres bases de données qui sont conformes à cette méta-données). En conséquence, je dois pouvoir appeler des choses comme:

string sql = "select " + USER_SELECTED_COLUMNS + 
            " from " + USER_SELECTED_TABLE + 
            " where " + USER_CRITERIA;

Certaines d'entre elles (comme le criteria) est littéralement entré dans mon programme par des utilisateurs de confiance (autres développeurs dans mon entreprise), tandis que d'autres données sont entrées dans mon programme par les utilisateurs non sécurisés (clients) dans leurs recherches, etc.

Je voudrais faire de ce programme sécurisé, et je suis conscient que ce qui précède n'est pas. À l'heure actuelle, j'ai le USER_SELECTED_COLUMNS remplacé par des paramètres de commande, mais je ne l'ai pas été en mesure de trouver l'équivalent pour les critères et TABLEs. (Ou l'ordre par des colonnes). Y at-il ADO.NET caractéristiques similaires à celles SqlParameter que je peux utiliser pour prédicats non-sélection?

Answer 1

Je ne pense pas que je pourrais vous dire comment éviter une injection SQL dans 1 réponse, cependant, le pointeur principal que je peux vous donner est la suivante:

USE listes blanches, pas LISTES NOIRES.

C'est-à-dire lors du nettoyage de l'entrée des utilisateurs pour USER_SELECTED_TABLE, l'entrée devrait être possible que les tableaux possibles. Equaly, l'entrée pour USER_SELECTED_COLUMNS devrait se limiter aux colonnes possibles pour USER_SELECTED_TABLE.

Answer 2

lorsque vous créez les écrans qui permettent à l'utilisateur de sélectionner la table et colonnes ne pas utiliser les noms réels. Type de la façon dont vous auriez un UserID mais montrer la UserName. Utilisez object_id et column_id (comme forme sys.tables.object_id, et sys.columns.object_id + column_id). Pas ceux dans votre procédure et de construire votre SQL en utilisant uniquement les identifiants numériques qui se joignent aux vues du système:

sys.tables (Transact-SQL)
sys.columns (Transact-SQL)

vous pouvez concaténer la table de chaîne et les noms de colonnes, mais ils vont venir des vues du système et non pas de l'entrée utilisateur.

Answer 3

Exécuter toutes les variables que vous avez indiquée ci-dessus par le Microsoft Web Protection Library . Il fournira la sécurité à la fois par injection SQL et des attaques XSS. Il y a des exemples dans le téléchargement pour vous montrer comment l'utiliser dans codebehind.