L’Approche de DataSunrise pour configurer les pénalités de détection d’injection 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 qui peuvent indiquer une injection potentielle. Lorsque la somme de ces pénalités dépasse un seuil prédéfini, DataSunrise prend des mesures, soit en consignant un avertissement (règle d’audit), soit en bloquant la requête purement et simplement (règle de sécurité).

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

Pénalité de commentaire

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

1. Exemple. Un exemple commun est de 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 cela réussit, il vous connectera en tant qu’utilisateur admin parce que le reste de la requête SQL après ‘–’ sera ignoré.

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

ID valeur: 10; DROP TABLE members /*

Éliminez simplement les autres éléments à la fin de la requête. Identique à 10; DROP TABLE members –

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

Une pénalité de mot-clé dans un commentaire

En continuant sur le thème des commentaires dans une requête, nous pouvons dire que les commentaires ordinaires peuvent se retrouver assez souvent dans des requêtes légitimes. Par exemple, de nombreux EDI 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’EDI dans laquelle la requête a été générée ou d’autres méta-informations. Par conséquent, un signe supplémentaire indiquant qu’un commentaire est suspect est 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é de double requête (empilement de requêtes)

L’empilement signifie exécuter 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--`

Lorsqu’il réussit, cela termine une requête et en commence une autre.

Toutes les bases de données ne supportent pas l’exécution de deux expressions ou plus dans une seule requête, mais là où c’est pris en charge, de tels 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 variables sont utilisées dans une seule expression. De telles demandes ne sont pas inhabituelles.

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

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

Cela donne 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 l’injection. Il en va de même pour les expressions qui retournent toujours TRUE ou FALSE.

Union Pénalité

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, l’accès aux autres tables est généralement vérifié

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

Lorsque vous effectuez une attaque d’injection SQL UNION, il existe deux méthodes efficaces pour déterminer le nombre de colonnes retournées par la requête d’origine.

Une méthode consiste à soumettre une série de charges utiles SELECT UNION 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 nulls 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 un nombre égal d’expressions dans leurs listes cibles.

Un attaquant utilise NULL comme valeurs retournées par la requête SELECT injectée parce que les types de données dans chaque colonne doivent être compatibles entre les requêtes d’origine et celles injectées. NULL est convertible en chaque type de données commun, maximisant ainsi les chances que la charge utile réussisse lorsque le nombre de colonnes est correct.

Pour réduire les chances de détecter une injection, DataSunrise détecte des UNIONS similaires 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, donnant à l’attaquant ou au testeur des informations pour 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’entre elles est les opérations qui essaient explicitement ou implicitement de convertir une valeur en un type auquel il ne peut pas être converti :

‘ and 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 comprendra une valeur de 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 aveugles basées sur des erreurs lorsque l’attaquant ne peut déterminer que s’il y a eu une erreur ou non.

Probablement le type de vérification le plus difficile d’un point de vue mise en œuvre. La raison en est qu’il existe un nombre énorme de possibilités pour provoquer une erreur.

Concaténation de Caractères Simples pour Plusieurs Types D’attaques

Un autre modèle souvent utilisé dans les attaques est l’échappement des données retourné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 voulons 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 telles conceptions sont suspectes 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 basées sur des erreurs. Dans ces cas, vous devez utiliser des injections SQL aveugles pour extraire les données. Il existe deux types de base 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 voir les effets de votre injection sous aucune forme de sortie. C’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 de 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 puis analyser les temps de réponse.

Exemples de fonctions d’attente/délai 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 demande contient des requêtes similaires souvent utilisées dans les attaques.

Condition Suspecte pour Vérifier une 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 structurellement 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 le booléen et basées sur le temps.

Dans ce type d’attaque, vous ne pouvez pas obtenir le résultat complet. L’attaquant cherche aveuglément à obtenir le contenu des tables qui l’intéressent, lettre par lettre. Cela peut être très long 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 attribue également des points de pénalité si des signes de telles requêtes sont détectés.

Pénalité de Compte Suspect

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

Le point est que si une injection SQL basée sur le temps est disponible, l’attaquant doit en quelque sorte distinguer entre deux branches d’exécution du code. Pour ce faire, une requête est exécutée dans l’une des branches, ce qui prend beaucoup de temps. Par exemple, compter le nombre de lignes dans une jointure de deux ou plusieurs tables. Lors du regroupement, les lignes se multiplient et beaucoup de lignes sont obtenues. Et COUNT fonctionne suffisamment longtemps pour que le script le remarque. Vous pouvez lire plus de détails ici. Dans cet article, vous trouverez le SLEEP(5), mais ce n’est que de la maternelle.

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

Conclusion

L’approche de DataSunrise pour configurer les pénalités pour la détection des 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. À travers 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 des injections SQL par DataSunrise souligne son engagement à fournir des solutions de sécurité des bases de données robustes. En tirant parti de techniques de détection avancées et en affinant continuellement son système de pénalité, DataSunrise permet aux organisations de protéger efficacement leurs actifs de données critiques contre les attaques par injection SQL.