L’opensource se qualifie par la formidable volonté de partage du travail avec le monde entier. Le revers de la médaille, c’est que ce monde entier n’est pas peuplé que de gens amicaux : il y a les « goods guys » et les « bad guys » (et Chuck Norris aussi 
). Il convient donc d’implémenter quelques protections de bases dans nos scripts pour préserver nos serveurs.
Toutes les attaques sont plus ou moins liées à des faiblesses dans l’initialisation des variables utilisées dans le script. Une dees plus courante, fort heureusement rarement possible, consiste à chercher dans les scripts une variable non initialisée mais utilisée, et en forcer la valeur, généralement en la passant en paramètre de l’url:
http://monsite.com/index.php?variable=bouh
-
<?php
-
-
echo $variable;
-
-
?>
Si notre php.ini est réglé sur « register_globals = on », le paramètre de l’url « variable=bouh » va résulter en la création de la variable php $variable, avec pour valeur « bouh ». Rien que ce petit script à première vue tout innocent se révèle une véritable bombe en puissance pour notre serveur ou nos utilisateurs : rien n’empêcherait en effet de passer de petits javascripts en paramètres et d’attraper ainsi un certain nombre de valeurs propre à l’internaute, ou de faire des choses encore moins avouables.
La première protection contre ce genre de chose consiste bien évidemment à s’assurer de notre php.ini. Ce n’est hélas pas toujours possible, car certaines applications nécessitent cette création automatique de variables.
Une deuxième protection – et c’est à mon sens une obligation quelque soit le langage et le contexte – consiste à explicitement fixer une valeur par défaut à toute les variables utilisées dans le script. Ainsi, nous éviterons tout eccueil en écrivant :
-
<?php
-
-
$variable = '';
-
echo $variable;
-
-
?>
Autre avantage : nous savons maintenant dès le début que notre $variable est prévue pour contenir une chaine de caractère.
Une troisième protection à noter – bien que ce ne soit pas ma préferrée – consiste en nettoyer toutes les $var portant le même nom qu’une entrée des tableaux de communication avec l’extèrieur ($_GET, $_POST, $_COOKIES, etc.), et de ne créer explicitement que les variables php attendues ($variable = $_GET['variable'] par exemple) après ce nettoyage. En d’autre mots, d’annuler cette création automatique de variables.
nb.: $GLOBALS est une variable php à part entière : nettoyez systématiquement de la mémoire toute entrée $_FOO['GLOBALS'] ($_FOO représentant $_POST, $_GET, etc.).
Un cas particulier : les variables globales utilisées dans les fichiers inclus
Bien souvent, une page va se structurer en un fichier principal incluant d’autres fichiers (par exemple une bibliothèque de fonction). Si le fichier inclut exécute quelques commandes en php (donc du code hors de fonctions et de méthodes), il devient alors un bon candidat à une attaque. En effet, il est conçu pour être exécuté dans un certain contexte (au sein du script l’incluant), mais devient alors appelable directement. Il convient donc de s’assurer qu’il ne sera exécutable que dans le contexte attendu. Le plus simple est de définir une constante pour qualifier cet environnement:
notre script principal
-
<?php
-
-
define('CONTEXT_SET', true);
-
$variable = 'Coucou';
-
-
include('./inc.echo.php');
-
-
?>
et notre fichier inc.echo.php
-
<?php
-
-
if ( !defined('CONTEXT_SET') )
-
{
-
die('Et puis quoi encore ?!?');
-
}
-
-
echo $variable;
-
-
?>
Comme une constante ne peut pas être définie de l’extèrieur du script, il n’y a pas de moyen d’exécuter notre inc.echo.php autrement qu’en l’incluant dans un script définissant la constante CONTEXT_SET.
Nous avons vu dans ce billet quelques méthodes pour s’assurer que nous n’allons pas utiliser de variable à la provenance douteuse. C’est un bon début 
. Nous verrons dans un prochain billet quelques règles de bases pour s’assurer du bon contenu des variables en provenance de l’extèrieur, car bon, on ne va pas non plus interdire toute saisie par l’utilisateur 
.
