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 ?
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.
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.
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 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
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.
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 Tue, 15 Mar 2011 15:39:56 +0100, Pascal Poncet a écrit:
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/
Le Tue, 15 Mar 2011 15:39:56 +0100, Pascal Poncet
<poncet.pascal.nospam@gmail.com.invalid> a écrit:
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/
Le Tue, 15 Mar 2011 15:39:56 +0100, Pascal Poncet a écrit:
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 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
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
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 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
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.
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
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. <Files ~ ".inc$"> Deny from all </Files>
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.
<Files ~ ".inc$">
Deny from all
</Files>
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
Mickael Wolff écrivait 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. <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.
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.
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.
-- Vainqueur du 1er WSOFRJCP
Mickael Wolff
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.
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.
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 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
Le 18 Jul 2011 07:41:45 GMT, Mickael Wolff <mickael.wolff@laposte.net>
é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).
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).
