Extension ".inc" = danger !

Le
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 ?

--
Cordialement,
Pascal
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mickael Wolff
Le #23206771
On 15/03/11 14:39, Pascal Poncet wrote:
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
Le #23207131
Le 15/03/2011 16:26, Mickael Wolff a écrit :
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.


--
Cordialement,
Pascal
DuboisP
Le #23207911
Le Tue, 15 Mar 2011 15:39:56 +0100, 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 ?




instructif...

argh, quelle horreur !
je vais modifier 2-3 trucs sur le site dont j'ai récupéré la gestion
--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/
Anthony
Le #23210341
Le 15/03/2011 15:39, Pascal Poncet a écrit :

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



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

Anthony
Fred
Le #23264531
Le 16/03/2011 23:19, Anthony a écrit :
Le 15/03/2011 15:39, Pascal Poncet a écrit :

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



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

Anthony




on dirait pas ;-)
Pascal Poncet
Le #23266941
Le 06/04/2011 22:45, Fred a écrit :
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.


--
Cordialement,
Pascal
Mickael Wolff
Le #23268701
On 07/04/11 20:30, Pascal Poncet wrote:
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.
Deny from all
</Files>
Thierry
Le #23529571
Mickael Wolff news:4d9e4631$0$24546$:

On 07/04/11 20:30, Pascal Poncet wrote:
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.
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.


--
Vainqueur du 1er WSOFRJCP
Mickael Wolff
Le #23577361
On 07/04/11 07:47, Thierry wrote:

[Apres la bataille]



Que puis-je dire ? :D

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)



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.

- 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
Le #23579171
Le 18 Jul 2011 07:41:45 GMT, Mickael Wolff écrivait dans fr.comp.lang.php:

On 07/04/11 07:47, Thierry wrote:

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
Publicité
Poster une réponse
Anonyme