Désactivez toutes les requêtes dans SQL Server qui n'utilisent pas les paramètres nommés?

Question

Il semble que l'on puisse arrêter toute menace d'injection SQL une fois pour toutes en rejetant simplement toutes les requêtes qui n'utilisent pas les paramètres nommés. Un moyen de configurer SQL Server pour le faire? Ou bien un moyen d'appliquer cela au niveau de l'application en inspectant chaque requête sans écrire un analyseur SQL entier? Merci.

Answer 1

Il n'y a que quelques façons de le faire. OMG PONIES a la meilleure réponse: n'autorisez pas les instructions SQL directes par rapport à votre base de données et exploitez plutôt les outils et la sécurité que SQL Server peut fournir.

Une autre manière serait d'ajouter un niveau supplémentaire que toutes les requêtes devraient passer. En bref, vous passez toutes les requêtes (architecture SOA) à une nouvelle application qui évaluerait la requête pour passer à SQL Server. J'ai vu exactement une entreprise faire cela en réaction aux problèmes d'injection de SQL que leur site avait.

Bien sûr, c'est une façon horrible de faire les choses parce que l'injection SQL n'est qu'un problème potentiel.

Au-delà de l'injection SQL, vous avez également des problèmes de ce qui se passe lorsque le site lui-même est fissuré. Une fois que vous pouvez écrire une nouvelle page sur un serveur Web, il devient trivial pour transmettre toute requête que vous souhaitez au serveur de base de données associé. Cela contournerait facilement n'importe quelle chose de niveau de code que vous pourriez mettre en place. Et cela permettrait à l'attaquant d'écrire select * from ... ou truncate table ... Heck, une personne interne pourrait potentiellement se connecter directement au serveur SQL à l'aide des informations d'identification des sites et exécuter toute requête qu'elle voulait.

Le fait est que si vous tirez parti de la sécurité intégrée à SQL Server pour éviter l'accès direct à la table, vous pouvez contrôler via des procédures stockées, la gamme complète d'actions disponible pour quiconque tente de se connecter au serveur.

Answer 2

1. Supprimer les subventions pour qu'un rôle puisse sélectionner / mettre à jour / insérer / supprimer contre le ou les tableaux impliqués
2. Grant exécuter le rôle des procédures / fonctions stockées / etc.
3. Associer le rôle à l'utilisateur de la base de données que vous souhaitez sécuriser

Il n'arrêtera pas un compte qui a également la possibilité d'accorder l'accès, mais il empêchera les utilisateurs associés à ce rôle (en supposant aucune autre subvention sur une base utilisateur) de pouvoir exécuter des requêtes en dehors de la procédure / fonctions stockées / etc qui existent.

Answer 3

Et comment voulez-vous vérifier cela? Les requêtes ont parfois des valeurs constantes qui seraient tout aussi faciles à ajouter à la requête. Par exemple, j'ai une base de données qui est prête à être multilingue, mais tout le code n'est pas, donc ma requête ressemble à ceci:

SELECT NAME FROM SOMETABLE WHERE ID = :ID AND LANGUAGEID = 1

L'ID est un paramètre, mais l'ID de langue n'est pas. Cette requête devrait-elle être bloquée?

Vous demandez à bloquer les requêtes qui n'utilisent pas les paramètres nommés. Qui peut être facilement appliqué. Bloquez simplement toute requête qui ne spécifie aucun paramètre. Vous pouvez le faire dans votre couche d'application. Mais il sera difficile de bloquer les requêtes comme celle ci-dessus, où une valeur est un paramètre et l'autre l'est. Vous devrez analyser cette requête pour le détecter, et ce sera aussi difficile.

Je ne pense pas que SQL Server ait des fonctionnalités intégrées pour ce faire.