Sécurité PHP

Il est d'usage de nommer les fichiers à inclure *.inc par exemple, ou même *.txt
Sauf précautions particulières, ceci est préjudiciable à la sécurité.
En effet, l'accès direct à un fichier *.inc en HTTP (http://site.free.fr/rep/fichier.inc) provoque généralement ... sa lecture en tant que texte brut !
On expose ainsi au vu de tous le contenu de tous les fichiers inclus.
Par exemple si on a un fichier compte.inc contenant les informations du compte, entre autre son mot de passe d'accès SQL, cela revient à divulguer ce mot de passe au monde entier.

Pour sécuriser ces fichiers inclus :

• On les rend exécutables par le moteur PHP (c'est à dire qu'on déclare dans le fichier de config Apache que les fichiers php sont les *.php et les *.inc)
  Ceci est impossible (modifier le fichier de config Apache) pour un client.
• On les protège par un .htaccess (avec un deny from all)
• On les nomme ... *.php !
  La demande http://site.free.fr/rep/fichier.php en provoque alors l'exécution et non la simple lecture.
  Le contenu n'est alors pas visible, du moins tout ce qui est entre <?php ... ?>
  Rappelons que lors d'un include, le moteur PHP repasse en mode html, ces balises <?php ... ?> sont donc toujours indispensables (pour repasser en mode php) dans l'inclus, à moins que l'inclus ne soit que du html, bien sûr. Mais dans ce cas il n'y a aucun risque : le contenu est de toute façon affiché et disponible au visiteur (fonction "afficher la source" du navigateur par exemple).

Un autre problème de sécurité avec les inclus vient des inclus dynamiques, où le nom du fichier vient d'un paramètre d'appel. Comme pour tout paramètre, il est indispensable de le vérifier avant de l'utiliser. Ici de vérifier que l'inclus demandé est bien un fichier du site !

On notera aussi que chez Free le include_path est site/include:.:...., donc par défaut on prend les fichiers inclus sans chemin explicite dans le répertoire include du site (nom imposé, comme 'sessions' pour les sessions). C'est seulement si le fichier demandé ne se trouve pas là qu'on cherche ailleurs (puis '.' le répertoire courant, puis ...)
Tant qu'à faire, autant regrouper tous les inclus dans ce répertoire là ! Et n'y mettre que des fichiers à inclure.
Il est alors facile de le protèger entièrement par un .htaccess avec Deny from all.
L'extension .inc ou autre des inclus n'a alors aucune importance.

Les paramètres de formulaires peuvent être récupérés dans des variables automatiques. Ainsi le champ toto (<input name="toto" ...> du formulaire) est récupéré directement dans la variable $toto
Ceci est controlé par le mode register_globals du fichier de config.
Quoi qu'il en soit, si register_globals est on, ceci pose un problème de sécurité :
Vous DEVEZ obligatoirement initialiser la moindre de vos variables, partout, sinon elle pourrait prendre une valeur imposée par un pirate ! (si celui-ci appelle votre script comme si c'était un formulaire, avec un "champ" fictif ayant pour nom le nom de la variable qu'il veut forcer).
Bon d'accord, une variable non initialisée est une erreur de programmation, mais quand même...
Ainsi, pour éviter ce risque, le gestionnaire du serveur a pu mettre register_globals à off.
Il vaut alors mieux utiliser explicitement les variables de formulaire en tant que $_POST['toto'], $_GET['toto'] ou $_REQUEST['toto'] qui fonctionne quel que soit l'état de register_globals.
$_REQUEST['toto'] est pour les fainéants : vous devez quand même bien savoir si votre formulaire utilise post ou get !