Pouvez-vous obtenir SQL CLR peut être d'excellente utilisation - vous pouvez au moins l'utiliser pour écrire beaucoup, une assassination beaucoup plus efficace que celle que l'on peut utiliser en T-SQL. Dans un monde perfacteur, vous pouvez remplacer complètement les processus stockés avec des déclarations paramétrées et d'autres structures plus fortes.

Avec ces contraintes, vous êtes assez vissé.

Voici une deux options qui pourraient vous donner une certaine direction:

1. Utilisez le validateur / analyseur de liste blanche qui n'acceptent que les requêtes qui sont dans un format et avec des mots-clés et des tables attendues. Cela fonctionnera probablement uniquement avec un très bon analyseur SQL qui comprend vraiment la syntaxe.

2. exécuter des requêtes dans un environnement restreint. Par exemple, utilisez un compte d'utilisateur avec des droits très limités. Par exemple, n'autorise que (lire) l'accès à certaines vues qui ne reviendront jamais de données sensibles et interdisent l'accès à toutes les autres vues, toutes les procédures, les fonctions et les tables stockées. Même plus sûr consiste à exécuter ces requêtes sur un autre serveur de base de données. N'oubliez pas non plus de désactiver le Commande OpenRowset .

   Veuillez noter les suivants:

   1. Lorsque vous acceptez toutes les requêtes, à l'exception de ceux qui ont des mots-clés non valides, vous échouerez certainement, car la liste noire échoue toujours. Surtout avec une langue aussi compliquée comme SQL.

   2. N'oubliez pas que, permettant à SQL dynamique de sources que vous ne pouvez pas faire confiance, c'est le mal dans son sens pur, même lorsque vous utilisez ces conseils, car une fois dans un moment Bugs sont découverts qui peuvent être abusés en envoyant une SQL spécialement conçue sur un serveur. Par conséquent, même si vous appliquez ces conseils, le risque est toujours là.

   3. Lorsque vous décidez d'aller avec une solution qui permet à SQL dynamique. S'il vous plaît, ne pensez pas que vous puissiez vous proposer une solution sûre, surtout si vous essayez de protéger les données commerciales sensibles. Embauchez un spécialiste de la sécurité du serveur de base de données pour vous aider à vous aider.

Il existe une autre approche qui peut-elle fonctionner éventuellement , bien que cela dépend de quels caractères sont autorisés dans les paramètres de la procédure stockée. Au lieu d'échapper aux caractères gênants pouvant être utilisés pour l'injection SQL, supprimez plutôt les caractères. Par exemple, si vous avez ce sp: xxx

Vous pouvez remplacer toutes les guillemets avec des espaces ou avec une chaîne vide. Cette approche peut également être utilisée pour remplacer des caractères de commentaire tels que / * * / - en utilisant plus de commandes Remplacer (comme je viens de montrer ci-dessus). Mais notez que cette approche ne fonctionnera que si vous ne vous attendez jamais à ces caractères en entrée normale, ce qui dépend de votre application.

Remarque L'ensemble des caractères remplacés est basé sur https://msdn.microsoft.com/en-us/library/ms161953 (SQL.105). ASPX