Injection SQL

L'injection SQL est une technique où un attaquant exploite les failles dans le code d'application responsable de la création de requêtes SQL dynamiques. L'attaquant peut accéder à des sections privilégiées de l'application, récupérer toutes les informations de la base de données, altérer des données existantes, voire exécuter des commandes dangereuses au niveau système sur l'hôte de la base de données. La vulnérabilité se produit lorsque les développeurs concatènent ou interpolent une entrée arbitraire dans leurs déclarations SQL.

Exemple #1 Séparation des résultats en pages, et créer des superutilisateurs (PostgreSQL)

Dans l'exemple suivant, l'entrée de l'utilisateur est directement interpolée dans la requête SQL, permettant à l'attaquant d'obtenir un compte superutilisateur dans la base de données.

<?php
$offset = $_GET['offset']; // Attention, aucune validation!
$query  = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
$result = pg_query($conn, $query);
?>

Un utilisateur normal clique sur les boutons 'suivant' et 'précédent', qui sont alors placés dans la variable $offset, encodée dans l'URL. Le script s'attend à ce que la variable $offset soit alors un nombre. Cependant, il est possible de modifier l'URL en ajoutant une nouvelle valeur, au format URL, comme ceci :

0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
    select 'crack', usesysid, 't','t','crack'
    from pg_shadow where usename='postgres';
--

Si cela arrive, le script donnerait un accès super utilisateur à l'attaquant. Il est à noter que la valeur 0; fournit un décalage valide à la requête originale et la termine correctement.

Note:
C'est une technique répandue que de forcer l'analyseur SQL à ignorer le reste de la requête, en utilisant les symboles -- pour mettre en commentaires.

Un moyen disponible pour accéder aux mots de passe est de contourner la recherche de page. Ce que le pirate doit faire, c'est simplement voir si une variable du formulaire est utilisée dans la requête, et si elle est mal gérée. Ces variables peuvent avoir été configurées dans une page précédente pour être utilisées dans les clauses WHERE, ORDER BY, LIMIT et OFFSET des requêtes SELECT. Si la base de données supporte les commandes UNION, le pirate peut essayer d'ajouter une requête entière pour lister les mots de passe dans n'importe quelle table. Utiliser la technique de stocker uniquement des hachages sécurisés des mots de passe au lieu des mots de passe eux-mêmes est fortement recommandé.

Exemple #2 Liste d'articles ... et quelques mots de passe (n'importe quel serveur de bases de données)

<?php
$query  = "SELECT id, name, inserted, size FROM products
           WHERE size = '$size'";
$result = odbc_exec($conn, $query);
?>

La partie statique de la requête, combinée avec une autre requête SELECT, va révéler les mots de passe :

'
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
--

Les instructions UPDATE et INSERT sont également susceptibles à de telles attaques

Exemple #3 Modifier un mot de passe ... et gain de droits ! (n'importe quel serveur de bases de données)

<?php
$query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
?>

Un internaute fourbe peut envoyer une valeur telle que ' or uid like'%admin% dans $uid pour modifier le mot de passe utilisateur, ou simplement, utiliser la variable $pwd avec la valeur hehehe', trusted=100, admin='yes pour obtenir des droits supplémentaires. La requête devient alors :

<?php

// $uid: ' or uid like '%admin%
$query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%';";

// $pwd: hehehe', trusted=100, admin='yes
$query = "UPDATE usertable SET pwd='hehehe', trusted=100, admin='yes' WHERE
...;";

?>

Bien qu'il reste évident qu'un attaquant doit posséder au moins certaines connaissances sur l'architecture de la base de données pour mener une attaque réussie, obtenir ces informations est souvent très simple. Par exemple, le code peut faire partie d'un logiciel open-source et être disponible publiquement. Ces informations peuvent également être divulguées par un code source fermé - même s'il est codé, obscurci ou compilé - et même par le code de l'application à travers l'affichage de messages d'erreur. D'autres méthodes comprennent l'utilisation de noms de table et de colonne typiques. Par exemple, un formulaire de connexion qui utilise une table 'users' avec des noms de colonnes 'id', 'username' et 'password'.

Exemple #4 Attaque du système d'exploitation de l'hôte de base de données (MSSQL Server)

Un exemple effrayant de la manière dont des commandes de niveau système d'exploitation peuvent être accessibles sur certains hôtes de base de données.

<?php
$query  = "SELECT * FROM products WHERE id LIKE '%$prod%'";
$result = mssql_query($query);
?>

Si le pirate injecte la valeur a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- dans la variable $prod, alors la requête $query devient :

<?php

$query  = "SELECT * FROM products
           WHERE id LIKE '%a%'
           exec master..xp_cmdshell 'net user test testpass /ADD' --%'";
$result = mssql_query($query);

?>

MSSQL Server exécute les requêtes SQL en lot, y compris la commande d'ajout d'un nouvel utilisateur à la base de données locale. Si cette application fonctionnait en tant que sa et que le service MSSQLSERVER disposait d'un niveau de droits suffisant, le pirate disposerait désormais d'un compte avec accès au serveur.

Note:
Certains exemples ci-dessus sont spécifiques à certains serveurs de bases de données, mais cela n'empêche pas des attaques similaires d'être possibles sur d'autres produits. La base de données sera alors vulnérable d'une autre manière.

Un exemple amusant concernant l'injection SQL

Image de » xkcd

Techniques de contournement

La méthode recommandée pour éviter les injections SQL est de lier toutes les données via des requêtes préparées. L'utilisation de requêtes paramétrées n'est pas suffisante pour éviter complètement les injections SQL, mais c'est le moyen le plus facile et le plus sûr de fournir une entrée aux instructions SQL. Toutes les valeurs littérales dynamiques dans les clauses WHERE, SET et VALUES doivent être remplacées par des espaces réservés. Les données réelles seront liées pendant l'exécution et envoyées séparément de la commande SQL.

La liaison de paramètres ne peut être utilisée que pour les données. Les autres parties dynamiques de la requête SQL doivent être filtrées contre une liste connue de valeurs autorisées.

Exemple #5 Éviter les injections SQL en utilisant des requêtes préparées PDO

<?php
 // La partie SQL dynamique est validée par rapport aux valeurs attendues
 $sortingOrder = $_GET['sortingOrder'] === 'DESC' ? 'DESC' : 'ASC';
 $productId = $_GET['productId'];
 // Le SQL est préparé avec un espace réservé
 $stmt = $pdo->prepare("SELECT * FROM products WHERE id LIKE ? ORDER BY price {$sortingOrder}");
 // La valeur est fournie avec des caractères génériques LIKE
 $stmt->execute(["%{$productId}%"]);
?>

Les instructions préparées sont fournies par PDO, par MySQLi, et par d'autres bibliothèques de bases de données.

Les attaques par injection SQL sont principalement basées sur l'exploitation du code qui n'a pas été écrit en tenant compte de la sécurité. Il ne faut jamais faire confiance à une entrée, en particulier côté client, même si elle provient d'une boîte de sélection, d'un champ de saisie masqué ou d'un cookie. Le premier exemple montre qu'une telle requête simple peut causer des désastres.

Une stratégie de défense en profondeur implique plusieurs bonnes pratiques de codage :

Il ne faut jamais se connecter à la base de données en tant que superutilisateur ou en tant que propriétaire de la base de données. Il convient de toujours utiliser des utilisateurs personnalisés avec des privilèges minimaux.
Il faut vérifier si l'entrée donnée a le type de données attendu. PHP a une large gamme de fonctions de validation d'entrée, des plus simples trouvées dans Fonctions de variables et dans Fonctions de type de caractères (par exemple is_numeric(), ctype_digit() respectivement) et jusqu'à la prise en charge des Expressions régulières compatibles avec Perl.
Si l'application s'attend à une entrée numérique, il convient de vérifier les données avec ctype_digit(), de changer silencieusement son type en utilisant settype(), ou d'utiliser sa représentation numérique avec sprintf().
Si la couche de base de données ne prend pas en charge la liaison de variables, alors il faut mettre chaque valeur fournie par l'utilisateur non numérique entre guillemets avec la fonction d'échappement de chaîne spécifique à la base de données (par exemple mysql_real_escape_string(), sqlite_escape_string(), etc.). Les fonctions génériques comme addslashes() ne sont utiles que dans un environnement très spécifique (par exemple MySQL dans un ensemble de caractères à octets uniques avec NO_BACKSLASH_ESCAPES désactivé), il est donc préférable de les éviter.
Il est particulièrement important de ne pas divulguer d'informations spécifiques à la base de données, en particulier sur le schéma, que ce soit de manière légale ou illégale. Se référer également à Rapport d'erreurs et Fonctions de gestion et de journalisation des erreurs.

À côté de ces conseils, il est recommandé d'enregistrer les requêtes, soit dans les scripts, soit dans la base elle-même, si elle le supporte. Évidemment, cet enregistrement ne sera pas capable d'empêcher une attaque, mais permettra de retrouver la requête qui a fauté. L'historique n'est pas très utile par lui-même mais au niveau des informations qu'il contient. Plus il y a de détails, mieux c'est.