Extension ".inc" = danger !

[Pascal Poncet]

Bonjour à tous,

On ne le répètera jamais assez, en PHP les fichiers inclus ne devraient
pas porter l'extension simple ".inc" car si l'on devine leur existence,
n'importe quel navigateur affichera directement leur contenu !

La preuve en direct (avant qu'ils ne modifient) :
http://sites.radiofrance.fr/franceinter/_c/php/emission/archives.inc

A la place, si l'on veut conserver l'indication d'inclusion, il est
conseillé et habituel d'utiliser l'extension double ".inc.php".
Évidemment, même chose pour les classes, avec ".class.php".

Une autre solution consiste à configurer le serveur pour qu'il passe ces
extensions simples au préprocesseur, mais ça me parait plus risqué,
surtout en cas de reconfiguration. Et puis comment lui indiquer le choix
du traitement si plusieurs langages sont utilisés ?

[Mickael Wolff]

Post by Pascal Poncet
Une autre solution consiste à configurer le serveur pour qu'il passe ces
extensions simples au préprocesseur, mais ça me parait plus risqué,
surtout en cas de reconfiguration. Et puis comment lui indiquer le choix
du traitement si plusieurs langages sont utilisés ?

Ceci dit, la meilleure solution consiste à ne jamais mettre les
fichiers PHP dans un répertoire accessible publiquement.
Je joue sur la directive de configuration include_path, et seul un
fichier index.php qui inclus un autre fichier PHP est présent dans le
répertoire publique servit par Apache, qui est configuré pour servir
tout contenu via le index.php (en utilisant les RewriteRule).

Je sais que toutes les applications publiées ici ou là ne le
permettent pas. Ceci dit, c'est une bonne base pour éviter tout les
problèmes de sécurité liés à un problème de configuration du serveur Web.

[Pascal Poncet]

Ceci dit, la meilleure solution consiste à ne jamais mettre les fichiers
PHP dans un répertoire accessible publiquement.
Je joue sur la directive de configuration include_path, et seul un
fichier index.php qui inclus un autre fichier PHP est présent dans le
répertoire publique servit par Apache, qui est configuré pour servir
tout contenu via le index.php (en utilisant les RewriteRule).
Je sais que toutes les applications publiées ici ou là ne le permettent
pas. Ceci dit, c'est une bonne base pour éviter tout les problèmes de
sécurité liés à un problème de configuration du serveur Web.

Tout ceci est parfaitement vrai, mais je faisais référence, certes de
façon un peu trop implicite, aux configurations de serveurs mutualisés,
qui représentent la plus grande part des volumes d'hébergement.
Ceux-ci ne permettent pas toujours d'accéder à une racine en amont de
celle de publication, hélas.
Je ne développe pas plus car ce serait hors charte, et cela ferait
plutôt partie d'un billet sur la façon de choisir son hébergement.

[DuboisP]

Le Tue, 15 Mar 2011 15:39:56 +0100, Pascal Poncet

Post by Pascal Poncet
Bonjour à tous,
On ne le répètera jamais assez, en PHP les fichiers inclus ne devraient
pas porter l'extension simple ".inc" car si l'on devine leur existence,
n'importe quel navigateur affichera directement leur contenu !
http://sites.radiofrance.fr/franceinter/_c/php/emission/archives.inc
A la place, si l'on veut conserver l'indication d'inclusion, il est
conseillé et habituel d'utiliser l'extension double ".inc.php".
Évidemment, même chose pour les classes, avec ".class.php".
Une autre solution consiste à configurer le serveur pour qu'il passe ces
extensions simples au préprocesseur, mais ça me parait plus risqué,
surtout en cas de reconfiguration. Et puis comment lui indiquer le choix
du traitement si plusieurs langages sont utilisés ?

instructif...

argh, quelle horreur !
je vais modifier 2-3 trucs sur le site dont j'ai récupéré la gestion

[Anthony]

Post by Pascal Poncet
http://sites.radiofrance.fr/franceinter/_c/php/emission/archives.inc

vous les avez prévenu au moins ? :-)

Anthony

[Fred]

Post by Anthony

Post by Pascal Poncet
http://sites.radiofrance.fr/franceinter/_c/php/emission/archives.inc

vous les avez prévenu au moins ? :-)
Anthony

on dirait pas ;-)

[Pascal Poncet]

Post by Fred

Post by Anthony
vous les avez prévenu au moins ? :-)

on dirait pas ;-)

Si, le pire, mais sont pas pressés !
D'abord il a fallu que je m'y prenne à deux fois, le temps de trouver le
bon interlocuteur.
Et puis, comme ils ont programmé une révision générale dans le courant
de l'été, tout est gelé d'ici là.
Certes, le fichier ne révèle pas de codes d'accès ou grosse indiscrétion
de ce genre, mais il donne quand même un début d'idée de la structure
applicative.

[Mickael Wolff]

Post by Pascal Poncet
Si, le pire, mais sont pas pressés !
D'abord il a fallu que je m'y prenne à deux fois, le temps de trouver le
bon interlocuteur.
Et puis, comme ils ont programmé une révision générale dans le courant
de l'été, tout est gelé d'ici là.

Quand on pense qu'une ligne dans la configuration d'Apache résoud le
problème.
<Files ~ "\.inc$">
Deny from all
</Files>

[Thierry]

Post by Mickael Wolff

Post by Pascal Poncet
Si, le pire, mais sont pas pressés !
D'abord il a fallu que je m'y prenne à deux fois, le temps de trouver le
bon interlocuteur.
Et puis, comme ils ont programmé une révision générale dans le courant
de l'été, tout est gelé d'ici là.

Quand on pense qu'une ligne dans la configuration d'Apache résoud le
problème.
<Files ~ "\.inc$">
Deny from all
</Files>

[Apres la bataille]

AMHA la meilleure solution c'est la double extension .inc.php:
- on ne peux pas tout le temps modifier le fichier de conf apache
(hebergeurs gratuits)
- en cas de migration on oubliera 2 fois sur 3 de modifier la conf.

[Mickael Wolff]

Post by Thierry
[Apres la bataille]

Que puis-je dire ? :D

Post by Thierry
- on ne peux pas tout le temps modifier le fichier de conf apache
(hebergeurs gratuits)

Donc le .inc.php n'a pas plus de permanence. Si le serveur web n'est
pas configuré pour traiter les fichiers PHP, le problème reste entier,
et c'est encore là un problème de configuration.

Post by Thierry
- en cas de migration on oubliera 2 fois sur 3 de modifier la conf.

Donc il faut faire en sorte que l'application casse, plutôt qu'elle
n'ait un comportement silencieux dangereux. D'oû la nécessité de ne
pousser que des fichiers simples et ne contenant que peu d'information
confidentielles dans les répertoires exportés publiquement.

[Denis Beauregard]

Post by Mickael Wolff
Donc il faut faire en sorte que l'application casse, plutôt qu'elle
n'ait un comportement silencieux dangereux. D'oû la nécessité de ne
pousser que des fichiers simples et ne contenant que peu d'information
confidentielles dans les répertoires exportés publiquement.

J'ai pris l'habitude de cacher la partie cruciale du code (le mode
de passe d'une BDD par exemple) dans un dossier privé, qui ne sera pas
affiché si le PHP n'est plus interprété.

Je pense qu'on pourrait étendre ce concept jusqu'à cacher les
algorithmes en soi dans ces dossiers privés, en généralisant les
include.

Le hic, c'est que souvent, il est possible de visiter le contenu du
site d'un autre client du même hébergeur, donc de voir le contenu de
ces dossiers privés, ceci parce qu'un fichier PHP doit être visible
par le serveur PHP et donc ne peut pas être protégé.

Ce n'est pas le cas de tous les hébergeurs. Ainsi, mon hébergeur
précédent me permettait de voir la liste des autres comptes sur le
même disque, donc de voir le code des autres clients, ce que mon
hébergeur courant ne permet pas. Mon nom de compte n'est pas celui
de mon site et j'ai observé cette tendance récente, ce qui me pousse
à écrire que cela est préconisé par les principaux constructeurs de
panneaux (cpanel ou plesk par exemple).


Denis

[Mickael Wolff]

Post by Denis Beauregard
Le hic, c'est que souvent, il est possible de visiter le contenu du
site d'un autre client du même hébergeur, donc de voir le contenu de
ces dossiers privés, ceci parce qu'un fichier PHP doit être visible
par le serveur PHP et donc ne peut pas être protégé.

En même temps, en hébergement mutualisé, il n'est pas possible de
parler de sécurité. On parlait d'accès aux données sensibles via le
serveur Web depuis l'extérieur, pas depuis l'intérieur ;)