Est-ce que ces motifs regex vont attraper toutes les injections SQL nécessaires?

Question

Nous avons changé nos règles de pare-feu (RegEx) à ce qui suit:

Name 
Type 
Context 
Severity 
Pattern 

CS:select_into 
signature 
http-url 
critical 
.*\[select\]\s+.*\[into\].* 

CS:select_from 
signature 
http-url 
critical 
.*\[select\]\s+.*\[from\].* 

CS:insert_into 
signature 
http-url 
critical 
.*\[insert\]\s+.*\[into\].* 

CS:drop_database 
signature 
http-url 
critical 
.*\[drop\]\s+.*\[database\].* 

CS:drop_table 
signature 
http-url 
critical 
.*\[drop\]\s+.*\[table\].* 

CS:delete_from 
signature 
http-url 
critical 
.*\[delete\]\s+.*\[from\].* 

CS:drop_view 
signature 
http-url 
critical 
.*\[drop\]\s+.*\[view\].* 

CS:exec 
signature 
http-url 
critical 
.*\[exec\].*(%28|\().*(%29|\)).* 

CS:update_set 
signature 
http-url 
critical 
.*\[update\](%20|\+)(%20|\+|.)*\[set\].* 

ce que ce bloc toutes les tentatives d'injection SQL? Par exemple, est-il possible de supprimer une vue en utilisant plusieurs espaces?

Answer 1

Une liste noire est la mauvaise approche. Il y aura toujours des choses auxquelles vous n'avez pas pensé, auxquelles l'attaquant pensera.

Quel langage de programmation/base de données utilisez-vous? Ils ont tous des méthodes pour transmettre des paramètres aux instructions SQL. Par exemple:

String userName = .... ; // from your GET or POST parameter 
String sql = "SELECT id FROM user where user_name=?"; 
ResultSet rs = executeSql(sql, userName); 

Voir http://en.wikipedia.org/wiki/SQL_injection#Parameterized_statements

Answer 2

Essayer d'empêcher l'injection sql en filtrant certains mots ne va pas travailler - il y aura toujours quelque chose que vous manquez et sera beaucoup de temps pour essayer de trouver tout couvrir. Vous devriez regarder des choses comme comment vous interrogez la base de données - si vous construisez SQL à la volée et concaténer les valeurs du client directement dans l'instruction, alors cela va être un domaine important sur lequel vous concentrer - passer à en utilisant des procédures SQL/paramétrées paramétrées. Les procédures stockées vous donneront également une couche de sécurité supplémentaire car vous pouvez accorder des autorisations pour les exécuter sans accorder d'autorisations directes sur les tables sous-jacentes.

Answer 3

Vous ne devez pas utiliser regex pour le filtrage d'entrée.

Vous devez filtrer vos entrées une par une avant de les transmettre au serveur SQL. Si vous insérez une chaîne (ou quoi que ce soit entre des apostrophes dans l'instruction sql), vous devez utiliser la fonction d'échappement de votre serveur sql, ce qui empêchera toute attaque.

Si vos données sont d'un type de nombre (entier ou flottant), vous devez vérifier si les données sont réellement un nombre (vous ne pouvez pas faire d'injection SQL sans lettres). La meilleure façon de le faire dépend du langage de programmation que vous utilisez, mais surtout des vérifications de type ou des catalogues forcés. Vous ne devez jamais insérer des données de type chaîne non fiables (tout ce qui vient d'un utilisateur n'est pas fiable) dans un état sqnd, où vous ne pouvez pas placer d'apostrophes, comme pour une table ou un nom de colonne.

Answer 4

Vous devez vous assurer que tout code SQL est uniquement exécuté via un compte à privilèges limités qui ne dispose d'aucune autorisation, sauf ceux dont l'application a explicitement besoin, plutôt que d'essayer d'intercepter toutes les permutations de SQL hostile.