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 qui vous permet de lire des fichiers tels que / etc / password , de modifier les connexions ethernet , lancer des impressions de documents , etc.. . Cela implique notamment que vous devez-vous assurer que les fichiers accédés par les scripts sont bien ceux qu ' il faut .

Considérez 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 .

Exemple 5-1 . Une erreur de vérification de variable conduit à .. .

 
?php

 
/

 
/

 
efface

 
un

 
fichier

 
dans

 
un

 
dossier

 
racine

 
$username

 
=

 
$HTTP_POST_VARS[

 
'user_submitted_name']

 
;

 
$homedir

 
=

 
"

 
/

 
home

 
/

 
$username"

 
;

 
$file_to_delete

 
=

 
"$userfile"

 
;

 
unlink

 
($homedir

 
/

 
$userfile)

 
;

 
echo

 
"$file_to_delete

 
a

 
été

 
effacé

 
!"

 
;

 
?



Etant donné que le nom de l'utilisateur est à fournir, des intrus peuvent envoyer un nom d'utilisateur autre que le leur, et effacer des documents dans les comptes des autres utilisateurs. Dans ce cas, vous souhaiterez utiliser une autre forme d'authentification. Considérez ce qui pourrait se passer si les utilisateurs passent "../etc/" et "passwd" comme arguments! Le code serait éxécuté tel que :

Exemple 5-2 . Une attaque du système de fichiers !

 
?php

 
/

 
/

 
efface

 
un

 
fichier

 
n'

 
importe

 


 
sur

 
le

 
disque

 
dur

 
,

 
/

 
/

 


 
l

 
'utilisateur

 
PHP

 
a

 
accès

 
.




 
Si

 
PHP

 
a

 
un

 
accès

 
root

 
:

 
$username

 
=

 
"

 
.

 
.

 
/

 
etc

 
/

 
"

 
;

 
$homedir

 
=

 
"

 
/

 
home

 
/

 
.

 
.

 
/

 
etc

 
/

 
"

 
;

 
$file_to_delete

 
=

 
"passwd"

 
;

 
unlink

 
("

 
/

 
home

 
/

 
.

 
.

 
/

 
etc

 
/

 
passwd")

 
;

 
echo

 
"

 
/

 
home

 
/

 
.

 
.

 
/

 
etc

 
/

 
passwd

 
a

 
été

 
effacé

 
!"

 
;

 
?



Il y a deux mesures primordiales à prendre pour éviter ces manoeuvres : Voici un script renforcé :

Exemple 5-3 . Une vérification renforcée

 
?php

 
/

 
/

 
Efface

 
un

 
fichier

 
sur

 
le

 
disque

 


 
l'

 
utilisateur

 
à

 
le

 
droit

 
d'aller

 
$username

 
=

 
$HTTP_SERVER_VARS['REMOTE_USER']

 
;

 
/

 
/

 
utilise

 
un

 
mécanisme

 
d'authentification

 
$homedir

 
=

 
"

 
/

 
home

 
/

 
$username"

 
;

 
$file_to_delete

 
=

 
basename("$userfile")

 
;

 
/

 
/

 
supprime

 
le

 
chemin

 
excédentaire

 
unlink

 
($homedir

 
/

 
$file_to_delete)

 
;

 
$fp

 
=

 
fopen("

 
/

 
home

 
/

 
logging

 
/

 
filedelete.log"

 
,"+a")

 
;

 
/

 
/note

 
l'effacement

 
$logstring

 
=

 
"$username

 
$homedir

 
$file_to_delete"

 
;

 
fputs

 
($fp

 
,

 
$logstring)

 
;

 
fclose($fp)

 
;

 
echo

 
"$file_to_delete

 
a

 
été

 
éffacé

 
!"

 
;

 
?



Cependant, même cette technique n'est pas sans faille. Si votre système d'identification permet aux utilisateurs de créer leur propre login, et qu'un utilisateur choisi le login "../etc/", le système est de nouveau exposé. Pour cette raison, vous pouvez essayez d'écrire un script renforcé :

Exemple 5-4 . Vérification de noms de fichier sécurisée

 
?php

 
$username

 
=

 
$HTTP_SERVER_VARS[

 
'REMOTE_USER'];

 
;

 
$homedir

 
=

 
"

 
/

 
home

 
/

 
$username"

 
;

 
if

 
(!ereg('^[^

 
.

 
/

 
][^

 
/

 
]*$'

 
,

 
$username)

 
)

 
die('Erreur

 
de

 
nom

 
de

 
fichier')

 
;

 
/

 
/meurt

 
,

 
ne

 
SURTOUT

 
pas

 
traiter

 
!

 
/

 
/etc..

 
.

 
?





Suivant votre système d' exploitation , vous devrez 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 stockages 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 que vous autorisez .