Existe-t-il un bon moyen d'analyser une instruction SQL pour s'assurer qu'elle ne contient qu'une instruction SELECT et rien d'autre? J'utilise C#, System.Data.SqlConnection et MS SQL ServerAnalyser une instruction SQL pour voir s'il s'agit d'une instruction autre que SELECT?
Vous devez vous connecter à la base de données en tant qu'utilisateur n'ayant pas l'autorisation de faire autre chose qu'un SELECT.
De cette manière, toute instruction non SELECT ne pourra pas être exécutée.
Il s'agit de la solution la plus sécurisée possible, à moins de dupliquer l'analyseur SQL Server.
Comme une instruction SELECT devrait être au tout début de l'instruction, vous pouvez simplement vérifier la chaîne pour voir si les 6 premiers caractères sont SELECT :
if (stringSql.Substring(0, 6).ToUpper() == "SELECT")
{
//execute statement
}
Ce serait un échec. Je pourrais écrire SELECT * FROM Users; SUPPRIMER des utilisateurs; –
Si la requête utilise un CTE, il commence par WITH, pas SELECT – Pondlife
Bon point ... mais Justin a raison; vous devriez être capable d'utiliser des paramètres pour vous protéger. – GendoIkari
assurez-vous que l'instruction commence par un mot-clé SELECT, puis assurez-vous que la déclaration ne contient pas de points-virgules (qui commencerait une autre instruction SQL) qui ne sont pas parties de chaînes de caractères.
SQL Server ne nécessite pas le point-virgule pour séparer les instructions – Rachel
La vérification d'un "point-virgule qui ne fait pas partie des chaînes littérales" signifie pour analyser la syntaxe, et comme certains commentaires à d'autres réponses énoncées, une déclaration select pourrait commencer par un "AVEC" ... – chiccodoro
@Rachel vraiment? Cela fait partie de la norme SQL de séparer les instructions avec des points-virgules. Ne créez pas d'interfaces graphiques qui vous permettent d'utiliser un terminateur différent avec le langage TSQL. –
Je suppose que vous pouvez trouver une expression régulière, mais il est probable qu'elle ne soit pas sûre à 100%. La meilleure façon d'y parvenir est de:
1. Ecrivez des procédures stockées et des vues, et limitez les droits de l'utilisateur à leur utilisation seulement. (et instructions SELECT sur certaines tables)
2. Générez un calque d'abstraction des données. Vous construisez les requêtes, pas quelqu'un d'autre. Laissez les autres accéder uniquement à certaines de vos méthodes exposées.
3. Utilisez LINQ to SQL, mais cachez l'objet DataContext, donc aucune modification de la base de données n'a pu être effectuée.
L'instruction sql doit être dynamique pour que les sprocs soient désactivés. C'est pour un moteur de QueryBuilder qui permet aux utilisateurs de sélectionner presque n'importe quoi de la base de données. Je préférerais également éviter LinqToSql puisque les utilisateurs d'administration sont ceux qui définissent ce qui peut être sélectionné dans la base de données, pas moi. – Rachel
Je pense que l'analyse syntaxique SQL sera la solution: from another question
Même avec ANTLR, ce sera encore très difficile et extrêmement facile de se tromper. (Vous avez besoin d'une grammaire complète et précise) – SLaks
D'accord, mais il bat la recherche du mot "SELECT" dans la chaîne de requête. Je me demande, si vous utilisez un objet SQLCommand, pouvez-vous vérifier la propriété CommandType avant l'exécution? – Kell
Non. CommandType vous permet de spécifier si le texte est une requête ou un sproc. Ce n'est jamais réglé automatiquement. – SLaks
Serais-je capable de créer un utilisateur sur SQL Server 2005/2008 qui puisse exécuter des procédures stockées en plus de n'importe quelle commande SELECT? – Rachel
@Rachel: Oui, vous pouvez. – SLaks
Pourquoi, oui, bien sûr. – AlexanderMP