Sécurité des bases de données

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().

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-6. 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 :

// 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;

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-7. 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-8. 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-9. 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-10. 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-11. 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-12. 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.