5.1.5.4 Injection SQL
5.1.5 Sécurité des bases de données
5.1 Sécurité
5 Sécurité
Manuel PHP
->Techniques de contournement
|
5.1.5.4.1 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
.
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.
|