Sécurité des fichiers PHP est soumis aux règles de sécurité intrinsèques de la plupart des systèmes serveurs : il respecte notamment les droits des fichiers et des dossiers. Une attention particulière doit être portée aux fichiers ou dossiers qui sont accessibles à tout le monde, afin de s'assurer qu'ils ne divulguent pas d'informations critiques. Puisque PHP a été fait pour permettre aux utilisateurs d'accéder aux fichiers, il est possible de créer un script PHP qui permet de lire des fichiers tels que /etc/passwd, de modifier les connexions ethernet, lancer des impressions de documents, etc. Cela implique notamment qu'il faut s'assurer que les fichiers manipulés par les scripts sont bien ceux qu'il faut. Dans le script suivant, l'utilisateur indique qu'il souhaite effacer un fichier dans son dossier racine. Nous supposons que PHP est utilisé comme interface web pour gérer les fichiers, et que l'utilisateur Apache est autorisé à effacer les fichiers dans le dossier racine des utilisateurs. Une erreur de vérification de variable conduit à un gros problème ]]> Étant donné que le nom de l'utilisateur et le nom du fichier sont fournis, des intrus peuvent envoyer un nom d'utilisateur et un nom de fichier autres que les leurs, et effacer des documents dans les comptes des autres utilisateurs. Dans ce cas, il est préférable d'utiliser une autre forme d'identification. Il faut considérer ce qui pourrait se passer si les utilisateurs passent ../etc/ et passwd comme arguments! Le code serait exécuté tel que : Une attaque du système de fichiers! ]]> Il y a deux mesures primordiales à prendre pour éviter ces manœuvres : Limiter les permissions de l'utilisateur web PHP. Vérifier toutes les variables liées aux chemins et aux fichiers qui sont fournis. Voici un script renforcé : Une vérification renforcée ]]> Cependant, même cette technique n'est pas sans faille. Si le système d'identification permet aux utilisateurs de créer leur propre login, et qu'un utilisateur choisit le login ../etc/, le système est de nouveau exposé. Pour cette raison, il est possible d'écrire un script renforcé : Vérification renforcée de noms de fichiers ]]> Suivant le système d'exploitation, il faudra protéger un grand nombre de fichiers, notamment les entrées de périphériques, (/dev/ ou COM1), les fichiers de configuration (fichiers /etc/ et .ini), les lieux de stockage d'informations (/home/, My Documents), etc. Pour cette raison, il est généralement plus sûr d'établir une politique qui interdit TOUT sauf ce qui est autorisé. Problèmes liés aux octets nuls Comme PHP utilise des fonctions C pour les opérations sous-jacentes, notamment au niveau du système de fichiers, il peut gérer les octets nuls d'une façon inattendue. Sachant que les octets nuls dénotent la fin d'une chaîne de caractères en C, certaines fonctions vont donc considérer ces chaînes jusqu'à la première occurrence d'un octet nul. L'exemple suivant présente un code vulnérable qui montre ce problème : Script vulnérable aux octets nuls ]]> Ainsi, toute chaîne utilisée dans des opérations sur le système de fichiers doit toujours être validée proprement. Voici une meilleure solution de l'exemple précédent : Validation correcte de l'entrée ]]>