L’approche de DataSunrise pour configurer des pénalités pour la détection d’injections SQL

L’injection SQL est une menace courante pour la sécurité des bases de données, où les attaquants manipulent des requêtes SQL pour obtenir un accès non autorisé aux données. DataSunrise, une solution de sécurité des bases de données, offre un mécanisme robuste pour détecter et prévenir les attaques par injection SQL grâce à un système de points de pénalité. Cet article explorera comment DataSunrise configure les pénalités pour différents types de modèles d’injection SQL et fournira des exemples de chacun.

Système de points de pénalité

Le système de points de pénalité de DataSunrise attribue une valeur numérique à divers composants d’une requête SQL pouvant indiquer une potentielle injection. Lorsque la somme de ces pénalités dépasse un seuil prédéfini, DataSunrise prend des mesures, soit en enregistrant un avertissement (règle d’audit) soit en bloquant la requête tout court (règle de sécurité).

Exemples de modèles d’injection SQL et pénalités

Pénalité de commentaire

Une des tâches de base d’un attaquant lorsqu’il essaie de faire une injection consiste à changer radicalement la requête. Pour cela, il doit désactiver/couper la partie de la requête qu’il ne contrôle pas ou qui l’empêcherait de réaliser l’injection. Pour ce faire, du code est ajouté à l’injection qui commentera cette partie de la requête qui se trouve après le bloc injecté. Voici quelques exemples.

1 Exemple. Un exemple courant consiste à se connecter en tant qu’administrateur :

Injection dans le paramètre de nom d’utilisateur : admin’–

SELECT * FROM members WHERE username = 'admin'--' AND password = 'password'

Si elle réussit, cela vous connectera en tant qu’utilisateur admin car le reste de la requête SQL après «–» sera ignoré.

2 Exemple. Exemples classiques d’attaque par injection SQL par commentaire en ligne

Valeur de l'ID : 10; DROP TABLE members /*

Il suffit de se débarrasser d’autres éléments à la fin de la requête. Idem pour 10; DROP TABLE members —

Par conséquent, la présence de commentaires dans la requête est l’un des signes d’une injection potentielle.

Pénalité pour un mot-clé dans un commentaire

En continuant le thème des commentaires dans une requête, nous pouvons dire que des commentaires ordinaires peuvent être trouvés assez souvent dans des requêtes légitimes. Par exemple, de nombreux IDE utilisés par les développeurs ajoutent automatiquement l’heure actuelle au début de la requête sous forme de commentaire ou la version de l’IDE dans laquelle la requête a été générée ou d’autres méta-informations. Par conséquent, un signe supplémentaire qu’un commentaire est suspect peut être la présence de mots-clés SQL tels que AND/OR/SELECT, etc.

Par exemple, dans l’expression SQL discutée ci-dessus

SELECT * FROM members WHERE username = 'admin'--' AND password = 'password'

Le mot-clé AND a été commenté.

Pénalité pour double requête (empilement de requêtes)

L’empilement signifie l’exécution de plus d’une requête dans une seule transaction. Cette technique peut être utile mais ne fonctionne que pour certaines combinaisons de serveur de base de données et de méthodes d’accès :

SELECT * FROM members; DROP members--`

En cas de succès, cela terminera une requête et en commencera une autre.

Toutes les bases de données ne prennent pas en charge l’exécution de deux ou plusieurs expressions dans une seule requête, mais là où c’est le cas, ces cas doivent être contrôlés.

DataSunrise ne génère pas d’erreurs si des expressions de configuration (SET et similaires) ou des requêtes de déclaration de variable sont utilisées dans une expression. De telles requêtes ne sont pas inhabituelles.

Pénalité OR + Pénalité d’expression constante

Souvent, pour utiliser une injection ou une autre, un attaquant doit créer une condition telle qu’elle soit vraie (TRUE). Et pour cela, la façon la plus simple peut être une opération OR avec une valeur qui est toujours vraie (TRUE). Par exemple, comme dans l’exemple : https://insecure-website.com/products?category=Gifts’+OR+1=1–

Cela se traduit par la requête SQL :

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

Dans ce cas, la requête affichera toutes les catégories, et pas seulement celles qui devraient.

Bien sûr, l’opération OR est courante et populaire dans le développement d’applications, mais avec d’autres signes, elle peut aider à détecter une injection. Il en va de même pour les expressions qui retournent toujours TRUE ou FALSE.

Pénalité UNION

Nos recherches ont montré que les cyberattaquants utilisent des outils automatisés qui les aident à identifier la possibilité théorique d’exploiter une vulnérabilité particulière. S’il est possible d’ajouter une expression supplémentaire à une requête vulnérable, alors la capacité d’accéder à d’autres tables est généralement vérifiée.

select id, id from products where name = 'Gifts' UNION SELECT NULL, NULL from SYS.USERS --'

Lorsque vous effectuez une attaque par injection SQL UNION, il existe deux méthodes efficaces pour déterminer combien de colonnes sont renvoyées par la requête originale.

Une méthode consiste à soumettre une série de charges utiles de type UNION SELECT en spécifiant un nombre différent de valeurs nulles :

' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL–, etc.

Si le nombre de valeurs nulles ne correspond pas au nombre de colonnes, la base de données renvoie une erreur, telle que :

Toutes les requêtes combinées à l’aide d’un opérateur UNION, INTERSECT ou EXCEPT doivent avoir le même nombre d’expressions dans leurs listes de cibles.

Un attaquant utilise NULL comme valeurs renvoyées par la requête SELECT injectée, car les types de données de chaque colonne doivent être compatibles entre les requêtes d’origine et les requêtes injectées. NULL est convertible en tous les types de données courants, ce qui maximise les chances que la charge utile réussisse lorsque le nombre de colonnes est correct.

Pour réduire les chances de détection de l’injection, DataSunrise détecte les UNION similaires qui sont utilisées lors de l’analyse des applications vulnérables et attribue des points de pénalité supplémentaires.

Conversion suspecte : Attaque par erreur

La technique d’injection SQL basée sur les erreurs force la base de données à générer une erreur, fournissant à l’attaquant ou au testeur des informations permettant d’affiner leur injection.

Pour forcer une application à générer une requête qui sera exécutée avec une erreur, de nombreuses techniques différentes sont utilisées. L’une d’elles est des opérations qui tentent explicitement ou implicitement de convertir une valeur en un type auquel elle ne peut pas être convertie :

‘ et 1=convert(int,(select top 1 table_name from information_schema.tables))--

Dans ce cas, une erreur sera générée, dont le texte inclura une valeur texte de la table système information_schema.tables.

Cependant, cette technique ne se limite pas à de telles attaques. Cette technique peut également être utilisée pour des attaques par erreur en aveugle lorsqu’un attaquant ne peut déterminer que s’il y avait ou non une erreur.

Probablement le type de vérification le plus difficile du point de vue de l’implémentation. La raison en est qu’il existe un nombre énorme de possibilités de provoquer une erreur.

Concaténation de caractères uniques pour de nombreux types d’attaques

Un autre modèle souvent utilisé dans les attaques consiste à échapper aux données renvoyées. Cela est souvent nécessaire lorsque le contenu de la page attaquée change fréquemment, et le script de vérification d’injection automatique doit utiliser des marqueurs spéciaux pour trouver la charge utile (les données précieuses que nous souhaitons extraire).

Par exemple,

AND 3516=CAST((CHR(113)||CHR(106)||CHR(122)||CHR(106)||CHR(113))||(SELECT (CASE WHEN (3516=3516) THEN 1 ELSE 0 END))::text||(CHR(113)||CHR(112)||CHR(106)||CHR(107)||CHR(113)) AS NUMERIC)

De tels modèles sont suspects pour DataSunrise.

Appel de fonction suspect

Dans toute application de production décente, vous ne pouvez généralement pas voir de réponses d’erreur sur la page. Cela exclut l’extraction de données directement via des attaques UNION ou des attaques basées sur des erreurs. Dans ces cas, vous devez utiliser des injections SQL aveugles pour extraire les données. Il existe deux types principaux d’injections SQL aveugles.

Injections aveugles normales. Vous ne pouvez pas voir la réponse directement sur la page, mais vous pouvez toujours déterminer le résultat d’une requête en fonction d’une réponse ou d’un code de statut HTTP.

Injections totalement aveugles. Vous ne pouvez pas voir les effets de votre injection dans aucun type de sortie. Cela est moins courant, par exemple lorsque vous injectez dans une fonction de journalisation ou similaire.

Dans les injections aveugles normales, vous pouvez utiliser des instructions IF ou abuser des clauses WHERE dans les requêtes, ce qui est généralement la voie la plus facile. Pour les injections totalement aveugles, vous devez utiliser une sorte de fonction d’attente et analyser ensuite les temps de réponse.

Exemples de fonctions d’attente/de temporisation disponibles :

WAITFOR DELAY '0:0:10' dans SQL Server
BENCHMARK() et sleep(10) dans MySQL
pg_sleep(10) dans PostgreSQL

DataSunrise attribue des points de pénalité supplémentaires si la requête contient des requêtes similaires souvent utilisées dans les attaques.

Condition suspecte pour vérifier l’attaque aveugle booléenne

L’injection SQL aveugle est un type d’injection SQL où l’attaquant ne reçoit pas de réponse évidente de la base de données attaquée et reconstruit à la place la structure de la base de données étape par étape en observant le comportement du serveur de base de données et de l’application. L’injection SQL aveugle est également appelée injection SQL inférentielle.

Il existe deux types d’injections SQL aveugles : basées sur des booléens et basées sur le temps.

Dans ce type d’attaque, vous ne pouvez pas obtenir le résultat complet. L’attaquant en vient à obtenir aveuglément le contenu des tables qui l’intéressent, lettre par lettre. Cela peut prendre beaucoup de temps et nécessite une bonne automatisation.

Voici un exemple de telle requête.

ORD(MID((SELECT grantee FROM(SELECT DISTINCT(grantee) FROM INFORMATION_SCHEMA.USER_PRIVILEGES LIMIT 0, 1) AS caou), 22, 1)) > 39--MnqX'

DataSunrise émet également des points de pénalité si des signes de telles requêtes sont détectés.

Pénalité de dénombrement suspect

Ce sont les points que DataSunrise attribue pour des blocs suspects dans SQL sous la forme SELECT count(*) FROM t1, t2.

L’idée est que si l’injection SQL basée sur le temps est disponible, l’attaquant doit différencier les deux branches d’exécution du code d’une manière ou d’une autre. Pour ce faire, une requête est exécutée dans l’une des branches, ce qui prend beaucoup de temps. Par exemple, le comptage du nombre de lignes dans une jointure de deux ou plusieurs tables. Lors de la jointure, les lignes sont multipliées et beaucoup de lignes sont obtenues. Et COUNT s’exécute suffisamment longtemps pour que le script le remarque. Vous pouvez en lire plus en détail ici. Dans cet article, vous trouverez le SLEEP(5), mais cela n’est que de l’enfance.

Beaucoup de gens ont déjà prouvé cela, et pour cette raison, ils utilisent des méthodes plus sophistiquées sous la forme de COUNT+JOIN, que nous avons décrites ci-dessus. En pratique normale, une telle requête, qui fait partie d’une requête plus complexe, n’est pas utilisée et peut donc servir comme l’un des signes d’injection.

Conclusion

L’approche de DataSunrise pour configurer des pénalités pour la détection d’injections SQL présente une stratégie complète et proactive pour protéger les bases de données contre cette menace omniprésente. En utilisant un système de points de pénalité qui évalue divers aspects des requêtes SQL, DataSunrise identifie et atténue efficacement les tentatives d’injection potentielles. Grâce à des exemples illustrant différents modèles d’injection SQL et les pénalités associées, cet article démontre la polyvalence et l’efficacité des mécanismes de détection de DataSunrise.

En essence, la configuration méticuleuse des pénalités pour la détection d’injections SQL par DataSunrise souligne son engagement à fournir des solutions de sécurité des bases de données robustes. En exploitant des techniques de détection avancées et en perfectionnant continuellement son système de pénalités, DataSunrise permet aux organisations de protéger efficacement leurs actifs de données critiques contre les attaques par injection SQL.