Analyse de T-SQL pour paramétrer une requête

Question

L'application sur laquelle je travaille actuellement génère un grand nombre de requêtes SQL en ligne. Tout le SQL généré est ensuite transféré à une classe d'exécution de base de données. Je veux écrire un service d'analyse syntaxique pour la classe d'exécution des données qui prendra une requête comme ceci:

SELECT field1, field2, field3 FROM tablename WHERE foo=1 AND bar="baz" 

et la transformer en quelque chose comme ceci:

SELECT field1, field2, field3 FROM tablename WHERE foo=@p1 AND bar=@p2 blah blah blah 

Toute chose déjà écrite qui accomplira cette pour moi dans C# ou vb.net? Ceci est destiné à combler un vide avant de refacturer le DAL pour ce projet.

MISE À JOUR: Les gars J'ai une énorme application qui a été portée de ASP classique vers ASP.NET avec littéralement des milliers de lignes de SQL en ligne. La seule grâce d'enregistrement est que tout le sql généré est transféré à une classe d'exécution de données. Je veux capturer le sql avant l'exécution et les paramétrer à la volée comme un frein à la réécriture de l'application entière.

Answer 1

Refactorisez maintenant.

Vous vous trompez si vous pensez que cette couche d'abstraction va pouvoir arriver plus rapidement et plus facilement.Au fond, vous savez que cela augmente le risque et l'incertitude sur le projet, mais vous voulez tuer le problème d'injection SQL ou tout autre problème que vous combattez avec une balle magique.

Le temps que vous prendriez pour écrire ce nouveau sous-système d'analyse et de test de régression du système, vous pourriez probablement remplacer tout le code en ligne par des appels à relativement moins de SP générés par code sur votre DB. De plus, vous pouvez le faire pièce par pièce. Pourquoi construire un code jetable important qui sera difficile à déboguer et ne correspond pas vraiment à ce à quoi l'architecture finale doit ressembler?

Answer 2

Ne faites pas cela. C'est beaucoup trop de travail. De plus, cette approche comporte de nombreux risques pour la sécurité. Examinez les objets Command et les requêtes paramétrées, au minimum.

Here is a small tutorial.

Answer 3

Je seconde la suggestion d'utiliser les paramètres de commande pour faire ce que vous voulez. Tout type d'analyse de chaîne de requête SQL demande simplement à quelqu'un de jouer à un jeu d'injection SQL avec vous. Un exemple de code est ci-dessous. La collection Parameters est facile à manipuler de façon normale

command.CommandText = "SELECT * FROM table WHERE key_field='?'" 
command.Parameters.Append command.CreateParameter(, 8, , , "value") '8 is adBSTR value 
set rsTemp = command.Execute 

Answer 4

o pense que votre tâche est trop honerous ... vous devez créer un analyseur très robuste ... je pense qu'il est préférable et plus facile de réécrire l'application départ , trouver des points où les requêtes sont générées et refactoriser le code.

Bon Loock!

Answer 5

Je ne peux penser qu'à un avantage que le paramétrage des requêtes à la volée apporterait: cela réduirait la vulnérabilité actuelle de votre application aux attaques par injection SQL. Dans tous les autres cas, le mieux que vous puissiez espérer est que ce parser/interpréteur hypothétique à la volée ne casse rien. Même si vous n'aviez pas à écrire une telle chose vous-même (et je parie que vous le faites), c'est un risque assez important à introduire dans un système de production, d'autant plus qu'il s'agit d'un palliatif à éliminer. l'application. Le risque d'une attaque par injection SQL est-il suffisamment élevé pour justifier cela?

Answer 6

Avez-vous envisagé d'exécuter une regex de substitution sur l'ancien code? Quelque chose qui va extraire les valeurs des requêtes en cours, les remplacer par des paramètres, et ajouter après la ligne de requête un appel Command.Parameters.AddWithValue (paramName, paramValue) peut être possible si le SQL inline actuel suit la même valeur (ou presque tous le font, et vous pouvez réparer le reste dans votre éditeur préféré).