Les plus grandes faiblesses de nombreux programmes PHP ne viennent pas
du langage lui-même, mais de son utilisation en omettant les
caractéristiques de sécurité. Pour cette raison,
vous devez toujours prendre le temps de prendre en compte les implications
d'une fonction, et de cerner toutes les applications d'une utilisation
exotiques des paramètres.
Exemple 30-1. Utilisation dangereuse de variables
<?php
// efface un fichier à la racine d'un utilisateur... ou peut être
// de quelqu'un d'autre?
unlink($evil_var);
// Note l'accès de ce fichier ... ou pas?
fputs($fp, $evil_var);
// Exécute une commande triviale... ou ajoute une entrée dans /etc/password ?
system($evil_var);
exec($evil_var);
?>
|
|
Il est vivement recommandé d'examiner minutieusement votre code
pour vous assurer qu'il n'y a pas de variables envoyées par le
client web, et qui ne sont pas suffisamment vérifiées avant utilisation.
Est-ce que ce script n'affectera que les fichiers prévus?
Est-il possible que des valeurs incohérentes soient exploitées ici?
Est-ce que ce script peut être utilisé dans un but différent?
Est-ce que ce script peut être utilisé malicieusement,
en conjonction avec d'autres?
Est-ce que toutes les actions seront notées?
En répondant de manière adéquate à ces questions
lors de l'écriture de vos scripts (plutôt qu'après), vous
éviterez une réécriture inopportune pour raison de
sécurité. En commençant vos projets avec ces recommandations
en tête, vous ne garantirez pas la sécurité de votre
système, mais vous contribuerez à l'améliorer.
Vous pouvez aussi envisager de supprimer l'acquisition automatique des
variables d'environnement, les guillemets magiques (magic_quotes),
ou encore toute option qui pourrait vous conduire à mésévaluer
la validité, la source ou la valeur d'une variable. En travaillant avec
error_reporting(E_ALL), vous pouvez être averti que certaines variables
sont utilisées avant d'être exploitées, ou
vérifiées (et donc, vous pourrez traiter des valeurs exotiques
à la source).
