Manuel PHP
Précédent | Chapitre 15. Sécurité | Suivant

# Sécurité des bases de données

De nos jours, les bases de données sont des composants incontournables des serveurs web et des applications en ligne, qui fournissent du contenu dynamique. Des données secrètes ou critiques peuvent être stockées dans les bases de données : il est donc important de les protéger efficacement.

Pour lire ou stocker des informations, vous devez vous connecter au serveur de bases de données, envoyer une requête valide, lire le résultat et refermer la connexion. De nos jours, le langage le plus courant pour ce type de communication est le langage SQL (Structured Query Language). Voyez comment un pirate peut s'introduire dans une requête SQL.

Comme vous pouvez le réaliser, `PHP` ne peut pas protéger vos bases de données pour vous. La section suivante vous introduira aux notions de base pour protéger vos bases de données, lors de la programmation de vos scripts.

Gardez bien cette règle simple en tête : la défense se fait par couches. Plus vous ajouterez de tests pour protéger votre base, plus faible sera la probabilité de réussite d'un pirate. Ajoutez à cela un bon schéma de base de données, et vous aurez une application réussie.

## Schéma de base de données

La première étape est de créer une base de données, à moins que vous ne souhaitiez utiliser une base de données déjà créée. Lorsque la base de données est créée, un utilisateur propriétaire en est responsable. Généralement, seul le propriétaire (et le super utilisateur) peuvent intervenir avec les tables de cette base, et il faut que ce dernier donne des droits à tous les intervenants qui auront à travailler sur cette base.

Les applications ne doivent jamais se connecter au serveur de bases de données sous le nom du propriétaire ou de l'administrateur, car ces utilisateurs ont des droits très importants, et pourront exécuter n'importe quelle requête, comme par exemple la modification de tables, l'effacement de lignes ou même encore, la destruction de la base.

Vous pouvez créer différents utilisateurs de bases de données pour chaque aspect de votre application, avec des droits limités aux seules actions planifiées. Il faut alors éviter que le même utilisateur dispose des droits de plusieurs cas d'utilisation. Cela permet que si des intrus obtiennent l'accès à la base avec l'un de ces jeux de droits, ils ne pourront pas affecter toute l'application.

Il est recommandé de ne pas implémenter toute la logique fonctionnelle dans l'application web (c'est-à-dire dans vos scripts), mais d'en reporter une partie dans la base en utilisant les triggers, vues et règles. Si le système évolue, les nouvelles versions vous feront réécrire toute la logique et donc tous vos scripts. De plus, l'utilisation de trigger permet de gérer de manière transparente des données, et fournit des indications pour déboguer votre application.

## Connexions au serveur de base de données

Il est recommandé d'établir des connexions au serveur avec le protocole SSL, pour chiffrer les échanges clients/serveur, afin d'améliorer la sécurité. Vous pouvez aussi utiliser un client SSH pour chiffrer la connexion entre les clients et le serveur de bases de données. Si l'une de ces deux protections est mise en place, il sera difficile de surveiller votre trafic et de comprendre les informations échangées.

## Modèle de stockage avec chiffrement

Les protocoles SSL/SSH protègent les données qui circulent entre le serveur et le client, mais SSL/SSH ne protègent pas les données une fois dans la base. SSL est un protocole en ligne.

Une fois que le pirate a obtenu l'accès direct à votre base de données (en contournant le serveur web), les données sensibles, stockées dans votre base sont accessibles directement, à moins que les données de la base ne soient protégées par la base. Chiffrer les données est une bonne solution pour réduire cette menace, mais très peut de bases de données offrent ce type de chiffrement.

Le moyen le plus simple pour contourner ce problème est de créer votre propre logiciel de chiffrement, et de l'utiliser dans vos scripts `PHP`. `PHP` peut vous aider dans cette tâche grâce aux nombreuses extensions dont il dispose, comme par exemple Mcrypt et Mhash, qui connaissent un large éventail de méthodes de chiffrement. Le script `PHP` va chiffrer les données qui seront stockées, et les déchiffrer losrqu'elles seront relues. Voyez la suite pour des exemples d'utilisation de ce chiffrement.

Dans le cas de données vraiment sensibles, si la représentation originale n'est pas nécessaire (pour affichage, ou comparaison), utiliser un hash est une bonne solution. L'exemple classique est le stockage de mots de passe dans les bases de données, après les avoir passé au MD5. Voyez les fonctions crypt() et md5().

Exemple 15-6. Utiliser un mot de passe et MD5

`// Stockage du mot de passe hashé
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
addslashes($username), md5($password));
$result = pg_exec($connection, $query);
// interroger le serveur pour comparer le mot de passe soumis
$query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
addslashes($username), md5($password));
$result = pg_exec($connection, $query);
if (pg_numrows($result) > 0) {
echo "Bienvenue, $username!";
}
else {
echo "Identification échouée pour $username.";
}`

## Injection SQL

De nombreux développeurs web ne sont pas conscients des possibilités de manipulation des requêtes SQL, et supposent que les requêtes SQL sont des commandes sûres. Cela signifie qu'une requête SQL est capable de contourner les contrôles et vérifications, comme par exemple les identifications et authentifications, et parfois, les requêtes SQL ont accès aux commandes d'administration.

L'injection SQL directe est une technique où un pirate modifie une requête SQL existante pour afficher des données cachées, ou pour écraser des valeurs importantes, ou encore exécuter des commandes dangereuses pour la base. Cela se fait lorsque l'application prend les données envoyées par l'internaute, et l'utilise directement pour contruire une requête SQL. Les exemples ci-dessous sont basés sur une histoire vraie, malheureusement.

Avec le manque de vérification des données de l'internaute et la connexion au serveur avec des droits de super utilisateur, le pirate peut créer des utilisateurs, et créer un autre super utilisateur.

Exemple 15-7. Séparation des résultats en pages, et créer des administrateurs (PostgreSQL et MySQL)

`$offset = argv[0]; // Attention, aucune validation! $query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;"; // avec PostgreSQL $result = pg_exec($conn, $query); // avec MySQL $result = mysql_query($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 décimal. Cependant, il est possible de modifier l'URL en ajoutant une nouvelle valeur, au format URL, comme ceci :

Exemple 15-8. Exemple d'injection SQL

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

    // cas de MySQL
    0;
    UPDATE user SET Password=PASSWORD('crack') WHERE user='root';
    FLUSH PRIVILEGES;

Si cela arrive, le script va créer un nouveau super utilisateur. Notez que la valeur `0;` sert à terminer la requête originale et la terminer correctement.

> Note : C'est une techinque répandue que de forcer l'analyseur SQL d'ignorer le reste de la requête, en utilisant les symboles `--` pour mettre en commentaire.

Un moyen possible 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 votre 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 des mots de passe chiffrés est fortement recommandé.

Exemple 15-9. Liste d'articles ... et ajout de mot de passe

`$query = "SELECT id, name, inserted, size FROM products WHERE size = '$size' ORDER BY $order LIMIT $limit, $offset;"; $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 :

Exemple 15-10. Révélation des mots de passe

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

Si cette requête (exploitant les `'` et `--`) est affectée à une variable utilisée dans `$query`, l'injection SQL va arriver.

Les commandes `UPDATE` sont aussi sujettes à des attaques de votre base de données. Ces requêtes peuvent aussi introduire toute une nouvelle requête dans votre commande initiale. Mais en plus, le pirate peut jouer sur la commande `SET`. Dans ce cas, il doit connaitre un peu votre base de données. Cela peut se deviner en examinant les noms de variables dans les formulaires, ou simplement, en testant les cas les plus classiques. Il n'y a pas beaucoup de conventions de nommination pour stocker des noms d'utilisateurs et des mots de passe.

Exemple 15-11. Modifier un mot de passe ... et gain de droits!

`$query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";`

Mais 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', admin='yes', trusted=100 "` (avec l'espace final) pour obtenir des droits supplémentaires. La requête sera alors devenue :

Exemple 15-12. Une requête et son injection

`// $uid == ' or uid like'%admin%'; -- $query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --"; // $pwd == "hehehe', admin='yes', trusted=100 " $query = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...;"`

C'est un exemple terrible d'acquisition de droits d'administrateur sur un serveur de base de données.

Exemple 15-13. Attaque d'un serveur de bases de données (MSSQL Server)

`$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 :

Exemple 15-14. Attaque d'un serveur de base de données (MSSQL Server) - 2

`$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 de niveau de droits suffisant, le pirate dispose désormais d'un compte avec accès au serveur.

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

### Techniques de contournement

Vous pouvez prétendre que le pirate doit d'abord obtenir des informations sur le schéma de la base de données, dans la plupart des cas d'injections. C'est vrai, mais vous ne saurez jamais comment ni quand ces informations auront filtré, et si cela arrive, votre base de données sera en grand danger. Si vous utilisez une base de données Open Srouce, ou une base qui est du domaine public, ou encore un schéma qui appartient à un système de gestion de contenu ou d'un forum, le pirate peut facilement se procurer une copie du code que vous utilisez. Cela peut être un risque potentiel si la base a été mal conçue.

Ces attaques sont généralement basées sur l'exploitation de code qui n'est pas écrit de manière sécuritaire. N'ayez aucune confiance dans les données qui proviennent de l'utilisateur, même si cela provient d'un menu déroulant, d'un champ caché ou d'un cookie. Le premier exemple montre comment une requête peut causer un désastre.

- Ne nous connectez jamais sur une base de données en tant que super utilisateur ou propriétaire de la base. Utilisez toujours un utilisateur adapté, avec des droits très limités.

- Vérifiez que les données ont bien le type attendu. `PHP` dispose d'un éventail de fonction de validation large, depuis les plus simples, de la section Variables et la section Caractères (e.g. is_numeric(), ctype_digit() respectivement) aux fonctions avancées de Expression régulière Perl.

- Si l'application attend une entrée numérique, vérifiez vos données avec la fonction is_numeric(), ou bien modifiez automatiquement le type avec la fonction settype(), ou encore avec sprintf().

  Exemple 15-15. Une navigation de fiches plus sécuritaire

  `<?php settype($offset, 'integer'); $query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;"; // notez que %d dans la chaîne de format : %s serait inutile $query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;", $offset); ?>`

- Mettez entre guillemet toutes les valeurs non numériques qui sont passées à la base de données, et protégez-vous des guillemets dans les valeurs avec la fonction addslashes() ou addcslashes(). Voyez le premier exemple. Comme les exemples l'on montré, les guillemets statiques peuvent être facilement contournés.

- N'affichez jamais d'informations spécifiques à la base, et notamment des informations concernant le schéma. Voyez aussi la section Rapport d'erreur et le chapitre Gestion des erreurs.

- Vous pouvez avoir des procédures stockées et des curseurs prédéfinis qui font que les utilisateurs n'ont pas un accès direct aux tables ou vues, mais cette solution a d'autres impacts.

A coté de ces conseils, il est recommandé d'enregistrer vos requêtes soit dans vos scripts soit dans la base elle-même, si elle le supporte. Evidemment, cet enregistrement ne sera pas capable d'empêcher une attaque, mais vous 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 vous avez de détails, mieux c'est.

Précédent | Sommaire | Suivant
Sécurité des fichiers | Niveau supérieur | Rapport d'erreurs