Bonjour messieurs les hébergeurs,
L'un de vous pourrait-il svp m'expliquer quel danger représente la fonction
realpath() en php qui n'est qu'une interrogation de chemin et pourquoi (au
moins) un hébergeur la bloque.
Merci
bretz
--------------------------------------------------------------------------------------
Messages vérifiés à la sortie par Norton Anti Virus 2004
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc Villemade
On 2005-09-05 14:14:02 +0200, "bretz" said:
Bonjour messieurs les hébergeurs, L'un de vous pourrait-il svp m'expliquer quel danger représente la fonction realpath() en php qui n'est qu'une interrogation de chemin et pourquoi (au moins) un hébergeur la bloque. Merci
bretz
Bonjour,
La fonction en elle meme ne pose pas de probleme de securite direct. Tu peux grace a la fonction deviner l'architecture filesysten de ton hebergeur ce qu'ils pourraient vouloir cacher.
La raison principale pour laquelle, imho, je disablerais la fonction en tant qu'hebergeur est parce que je suis encore dans une version anterieur a 4.3.9 et/ou 5.0.2 car il y avait une faille qui permettait de recuperer des fichiers auxquels tu n'avais normalement pas droit ..
Pour info: http://xforce.iss.net/xforce/xfdb/18512
A bientot
-- Marc
On 2005-09-05 14:14:02 +0200, "bretz" <TOREMOVEbyebretz@yahooDOT.fr> said:
Bonjour messieurs les hébergeurs,
L'un de vous pourrait-il svp m'expliquer quel danger représente la
fonction realpath() en php qui n'est qu'une interrogation de chemin et
pourquoi (au moins) un hébergeur la bloque.
Merci
bretz
Bonjour,
La fonction en elle meme ne pose pas de probleme de securite direct. Tu
peux grace a la fonction deviner l'architecture filesysten de ton
hebergeur ce qu'ils pourraient vouloir cacher.
La raison principale pour laquelle, imho, je disablerais la fonction en
tant qu'hebergeur est parce que je suis encore dans une version
anterieur a 4.3.9 et/ou 5.0.2 car il y avait une faille qui permettait
de recuperer des fichiers auxquels tu n'avais normalement pas droit ..
Pour info:
http://xforce.iss.net/xforce/xfdb/18512
Bonjour messieurs les hébergeurs, L'un de vous pourrait-il svp m'expliquer quel danger représente la fonction realpath() en php qui n'est qu'une interrogation de chemin et pourquoi (au moins) un hébergeur la bloque. Merci
bretz
Bonjour,
La fonction en elle meme ne pose pas de probleme de securite direct. Tu peux grace a la fonction deviner l'architecture filesysten de ton hebergeur ce qu'ils pourraient vouloir cacher.
La raison principale pour laquelle, imho, je disablerais la fonction en tant qu'hebergeur est parce que je suis encore dans une version anterieur a 4.3.9 et/ou 5.0.2 car il y avait une faille qui permettait de recuperer des fichiers auxquels tu n'avais normalement pas droit ..
Pour info: http://xforce.iss.net/xforce/xfdb/18512
A bientot
-- Marc
bretz
Merci pour cette réponse, L'hébergeur en question est en php 4.3.10-2 et donc ne devrait pas être touché. J'utilise en développement un RAD qui lui même fait appel à cette fonction et, pour des questions de compatibilité et d'évolution je n'ai pas envie d'aller modifier le RAD lui-même. Cet hébergeur bloque également : get_current_user, php_uname, putenv, set_time_limit, getmyuid, getmypid, dl, ini_alter, ini_restore, ini_set, exec, passthru, system, popen, leak, mysql_list_dbs, mysql_list_processes, socket_bind, socket_listen, chown, chmod (tout est mis en 745 ce qui bloque les écriture par des programmes "included") , chgrp, diskfreespace, rmdir, realpath, tmpfile, link, imap_mail, proc_open ce qui me bloque complètement. Bref je vais codé en php pur et dur en ce qui concerne la partie administrative du site et perdre quelques jours de travail... Ici cet hébergeur annonce clairement la couleur dans son phpinfo que j'aurai dû mieux examiner mais j'ai déjà eu le cas d'un hébergeur (connu et de qualité) qui bloque certaines fonctions (fopen()) sans rien annoncer ni dans le phpinfo, ni dans les faq avec les désagréments que l'on peut imaginer. Existe-t-il un moyen de découvrir à priori les fonctions bloquées par les hébergheurs ? Bien à vous Bretz
Marc Villemade wrote:
On 2005-09-05 14:14:02 +0200, "bretz" said:
Bonjour messieurs les hébergeurs, L'un de vous pourrait-il svp m'expliquer quel danger représente la fonction realpath() en php qui n'est qu'une interrogation de chemin et pourquoi (au moins) un hébergeur la bloque. Merci
bretz
Bonjour,
La fonction en elle meme ne pose pas de probleme de securite direct. Tu peux grace a la fonction deviner l'architecture filesysten de ton hebergeur ce qu'ils pourraient vouloir cacher.
La raison principale pour laquelle, imho, je disablerais la fonction en tant qu'hebergeur est parce que je suis encore dans une version anterieur a 4.3.9 et/ou 5.0.2 car il y avait une faille qui permettait de recuperer des fichiers auxquels tu n'avais normalement pas droit ..
Pour info: http://xforce.iss.net/xforce/xfdb/18512
A bientot
Merci pour cette réponse,
L'hébergeur en question est en php 4.3.10-2 et donc ne devrait pas être
touché.
J'utilise en développement un RAD qui lui même fait appel à cette fonction
et, pour des questions de compatibilité et d'évolution je n'ai pas envie
d'aller modifier le RAD lui-même.
Cet hébergeur bloque également : get_current_user, php_uname, putenv,
set_time_limit, getmyuid, getmypid, dl, ini_alter, ini_restore, ini_set,
exec, passthru, system, popen, leak, mysql_list_dbs, mysql_list_processes,
socket_bind, socket_listen, chown, chmod (tout est mis en 745 ce qui bloque
les écriture par des programmes "included") , chgrp, diskfreespace, rmdir,
realpath, tmpfile, link, imap_mail, proc_open ce qui me bloque complètement.
Bref je vais codé en php pur et dur en ce qui concerne la partie
administrative du site et perdre quelques jours de travail...
Ici cet hébergeur annonce clairement la couleur dans son phpinfo que j'aurai
dû mieux examiner mais j'ai déjà eu le cas d'un hébergeur (connu et de
qualité) qui bloque certaines fonctions (fopen()) sans rien annoncer ni dans
le phpinfo, ni dans les faq avec les désagréments que l'on peut imaginer.
Existe-t-il un moyen de découvrir à priori les fonctions bloquées par les
hébergheurs ?
Bien à vous
Bretz
Marc Villemade wrote:
On 2005-09-05 14:14:02 +0200, "bretz" <TOREMOVEbyebretz@yahooDOT.fr>
said:
Bonjour messieurs les hébergeurs,
L'un de vous pourrait-il svp m'expliquer quel danger représente la
fonction realpath() en php qui n'est qu'une interrogation de chemin
et pourquoi (au moins) un hébergeur la bloque.
Merci
bretz
Bonjour,
La fonction en elle meme ne pose pas de probleme de securite direct.
Tu peux grace a la fonction deviner l'architecture filesysten de ton
hebergeur ce qu'ils pourraient vouloir cacher.
La raison principale pour laquelle, imho, je disablerais la fonction
en tant qu'hebergeur est parce que je suis encore dans une version
anterieur a 4.3.9 et/ou 5.0.2 car il y avait une faille qui permettait
de recuperer des fichiers auxquels tu n'avais normalement pas droit ..
Pour info:
http://xforce.iss.net/xforce/xfdb/18512
Merci pour cette réponse, L'hébergeur en question est en php 4.3.10-2 et donc ne devrait pas être touché. J'utilise en développement un RAD qui lui même fait appel à cette fonction et, pour des questions de compatibilité et d'évolution je n'ai pas envie d'aller modifier le RAD lui-même. Cet hébergeur bloque également : get_current_user, php_uname, putenv, set_time_limit, getmyuid, getmypid, dl, ini_alter, ini_restore, ini_set, exec, passthru, system, popen, leak, mysql_list_dbs, mysql_list_processes, socket_bind, socket_listen, chown, chmod (tout est mis en 745 ce qui bloque les écriture par des programmes "included") , chgrp, diskfreespace, rmdir, realpath, tmpfile, link, imap_mail, proc_open ce qui me bloque complètement. Bref je vais codé en php pur et dur en ce qui concerne la partie administrative du site et perdre quelques jours de travail... Ici cet hébergeur annonce clairement la couleur dans son phpinfo que j'aurai dû mieux examiner mais j'ai déjà eu le cas d'un hébergeur (connu et de qualité) qui bloque certaines fonctions (fopen()) sans rien annoncer ni dans le phpinfo, ni dans les faq avec les désagréments que l'on peut imaginer. Existe-t-il un moyen de découvrir à priori les fonctions bloquées par les hébergheurs ? Bien à vous Bretz
Marc Villemade wrote:
On 2005-09-05 14:14:02 +0200, "bretz" said:
Bonjour messieurs les hébergeurs, L'un de vous pourrait-il svp m'expliquer quel danger représente la fonction realpath() en php qui n'est qu'une interrogation de chemin et pourquoi (au moins) un hébergeur la bloque. Merci
bretz
Bonjour,
La fonction en elle meme ne pose pas de probleme de securite direct. Tu peux grace a la fonction deviner l'architecture filesysten de ton hebergeur ce qu'ils pourraient vouloir cacher.
La raison principale pour laquelle, imho, je disablerais la fonction en tant qu'hebergeur est parce que je suis encore dans une version anterieur a 4.3.9 et/ou 5.0.2 car il y avait une faille qui permettait de recuperer des fichiers auxquels tu n'avais normalement pas droit ..
Pour info: http://xforce.iss.net/xforce/xfdb/18512
A bientot
Spyou
Existe-t-il un moyen de découvrir à priori les fonctions bloquées par les hébergheurs ?
Leur demander ?
Existe-t-il un moyen de découvrir à priori les fonctions bloquées par
les hébergheurs ?
Existe-t-il un moyen de découvrir à priori les fonctions bloquées par les hébergheurs ?
Leur demander ?
bretz
Spyou wrote:
Existe-t-il un moyen de découvrir à priori les fonctions bloquées par les hébergheurs ?
Leur demander ? Bonjour
Dans leurs contrats les hébergeurs indiquent ce qu'ils ne veulent pas comme par exemple la pornographie, ce qui a trait au racisme ... etc ceci afin de SE protéger. Dans leurs contrats ils ne font (pour ceux que j'en connais) pas mention des fonctions qu'ils bloquent, est-ce par oubli ? ou alors n'est-ce pas important ! Bien à vous Bretz
Spyou wrote:
Existe-t-il un moyen de découvrir à priori les fonctions bloquées par
les hébergheurs ?
Leur demander ?
Bonjour
Dans leurs contrats les hébergeurs indiquent ce qu'ils ne veulent pas comme
par exemple la pornographie, ce qui a trait au racisme ... etc ceci afin de
SE protéger.
Dans leurs contrats ils ne font (pour ceux que j'en connais) pas mention des
fonctions qu'ils bloquent, est-ce par oubli ? ou alors n'est-ce pas
important !
Bien à vous
Bretz
Existe-t-il un moyen de découvrir à priori les fonctions bloquées par les hébergheurs ?
Leur demander ? Bonjour
Dans leurs contrats les hébergeurs indiquent ce qu'ils ne veulent pas comme par exemple la pornographie, ce qui a trait au racisme ... etc ceci afin de SE protéger. Dans leurs contrats ils ne font (pour ceux que j'en connais) pas mention des fonctions qu'ils bloquent, est-ce par oubli ? ou alors n'est-ce pas important ! Bien à vous Bretz
R12y
On Tue, 06 Sep 2005 17:54:21 +0200, bretz wrote:
Leur demander ? Dans leurs contrats [...]
Dans leurs contrats
Spyou n'a pas suggéré de regarder dans les contrats, mais de "demander". Par mail, par téléphone,... Justement parceque ça n'est pas toujours écrit dans le contrat.
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
On Tue, 06 Sep 2005 17:54:21 +0200, bretz wrote:
Leur demander ?
Dans leurs contrats [...]
Dans leurs contrats
Spyou n'a pas suggéré de regarder dans les contrats, mais de "demander".
Par mail, par téléphone,... Justement parceque ça n'est pas
toujours écrit dans le contrat.
--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/
Spyou n'a pas suggéré de regarder dans les contrats, mais de "demander". Par mail, par téléphone,... Justement parceque ça n'est pas toujours écrit dans le contrat.
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
Mickaël Wolff
Existe-t-il un moyen de découvrir à priori les fonctions bloquées par les hébergheurs ? Regarder le phpinfo généralement fournit ?
dans (in) fr.reseaux.internet.hebergement, "bretz" ecrivait (wrote) :
Bonsoir,
Dans leurs contrats les hébergeurs indiquent ce qu'ils ne veulent pas comme par exemple la pornographie, ce qui a trait au racisme ... etc ceci afin de SE protéger.
Oui. Ce sont des généralités, ça, le plus souvent dictées par la législation.
Dans leurs contrats ils ne font (pour ceux que j'en connais) pas mention des fonctions qu'ils bloquent, est-ce par oubli ? ou alors n'est-ce pas important !
Les fonctions en question ne sont généralement pas mentionnées directement dans les contrats d'hébergement, parce qu'elles sont par définition fluctuantes car les failles de sécurité ne se devinent pas à l'avance, ni leurs conséquences, et que les lister à un moment M serait peu pertinent.
En revanche concernant PHP, comme le faisait remarquer Mickaël, les hébergeurs sérieux proposent un accès à phpinfo(), permettant de savoir précisément quelles sont les fonctions disponibles sur leurs serveurs.
Il ne faut pas perdre de vue que dans la majorité des cas, les limitations ne sont pas imposées pour pénaliser le client, mais au contraire pour le protéger.
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, "bretz"
<TOREMOVEbyebretz@yahooDOT.fr> ecrivait (wrote) :
Bonsoir,
Dans leurs contrats les hébergeurs indiquent ce qu'ils ne veulent pas comme
par exemple la pornographie, ce qui a trait au racisme ... etc ceci afin de
SE protéger.
Oui. Ce sont des généralités, ça, le plus souvent dictées par la
législation.
Dans leurs contrats ils ne font (pour ceux que j'en connais) pas mention des
fonctions qu'ils bloquent, est-ce par oubli ? ou alors n'est-ce pas
important !
Les fonctions en question ne sont généralement pas mentionnées
directement dans les contrats d'hébergement, parce qu'elles sont par
définition fluctuantes car les failles de sécurité ne se devinent pas à
l'avance, ni leurs conséquences, et que les lister à un moment M serait
peu pertinent.
En revanche concernant PHP, comme le faisait remarquer Mickaël, les
hébergeurs sérieux proposent un accès à phpinfo(), permettant de savoir
précisément quelles sont les fonctions disponibles sur leurs serveurs.
Il ne faut pas perdre de vue que dans la majorité des cas, les
limitations ne sont pas imposées pour pénaliser le client, mais au
contraire pour le protéger.
dans (in) fr.reseaux.internet.hebergement, "bretz" ecrivait (wrote) :
Bonsoir,
Dans leurs contrats les hébergeurs indiquent ce qu'ils ne veulent pas comme par exemple la pornographie, ce qui a trait au racisme ... etc ceci afin de SE protéger.
Oui. Ce sont des généralités, ça, le plus souvent dictées par la législation.
Dans leurs contrats ils ne font (pour ceux que j'en connais) pas mention des fonctions qu'ils bloquent, est-ce par oubli ? ou alors n'est-ce pas important !
Les fonctions en question ne sont généralement pas mentionnées directement dans les contrats d'hébergement, parce qu'elles sont par définition fluctuantes car les failles de sécurité ne se devinent pas à l'avance, ni leurs conséquences, et que les lister à un moment M serait peu pertinent.
En revanche concernant PHP, comme le faisait remarquer Mickaël, les hébergeurs sérieux proposent un accès à phpinfo(), permettant de savoir précisément quelles sont les fonctions disponibles sur leurs serveurs.
Il ne faut pas perdre de vue que dans la majorité des cas, les limitations ne sont pas imposées pour pénaliser le client, mais au contraire pour le protéger.
-- Eric Demeester - http://www.galacsys.net
GPLHost
bretz wrote:
Cet hébergeur bloque également : [...] getmyuid, getmypid, chown, chmod (tout est mis en 745 ce qui bloque les écriture par des programmes "included") , chgrp, diskfreespace, rmdir, realpath, tmpfile, link, imap_mail, proc_open ce qui me bloque complètement.
Je ne comprend pas trop ce qui a été essayé de faire en faisant toute ces limitations, mais mon commentaire c'est que j'ai l'impression que ton hébergeur ne sait pas ce qu'il fait niveau sécurité.
Bloquer les fonctions genre rmdir, chgrp, chmod et autre semble etre une tentative de restriction des droits pour éviter qu'un utilisateur n'écrive un peu partout sur le disque. En effet, c'est le seul intéret, puisque cela gène un utilisateur de compte mutualisé.
Seulement le hic, c'est que normalement il n'y a pas besoin de cela si on utilise judicieusement la directive "open_basedir" de php. Ne pas l'utiliser est a mon avis une grave erreur, et si on l'utilise, on a plus besoin de limiter les chown/chmod, etc. Donc au final, je ne vois pas l'interet d'une tel restriction. Bref c'est louche tout ça ! :)
Thomas
bretz wrote:
Cet hébergeur bloque également : [...] getmyuid, getmypid,
chown, chmod (tout est
mis en 745 ce qui bloque les écriture par des programmes "included") ,
chgrp, diskfreespace, rmdir, realpath, tmpfile, link, imap_mail,
proc_open ce qui me bloque complètement.
Je ne comprend pas trop ce qui a été essayé de faire en faisant toute
ces limitations, mais mon commentaire c'est que j'ai l'impression que
ton hébergeur ne sait pas ce qu'il fait niveau sécurité.
Bloquer les fonctions genre rmdir, chgrp, chmod et autre semble etre une
tentative de restriction des droits pour éviter qu'un utilisateur
n'écrive un peu partout sur le disque. En effet, c'est le seul intéret,
puisque cela gène un utilisateur de compte mutualisé.
Seulement le hic, c'est que normalement il n'y a pas besoin de cela si
on utilise judicieusement la directive "open_basedir" de php. Ne pas
l'utiliser est a mon avis une grave erreur, et si on l'utilise, on a
plus besoin de limiter les chown/chmod, etc. Donc au final, je ne vois
pas l'interet d'une tel restriction. Bref c'est louche tout ça ! :)
Cet hébergeur bloque également : [...] getmyuid, getmypid, chown, chmod (tout est mis en 745 ce qui bloque les écriture par des programmes "included") , chgrp, diskfreespace, rmdir, realpath, tmpfile, link, imap_mail, proc_open ce qui me bloque complètement.
Je ne comprend pas trop ce qui a été essayé de faire en faisant toute ces limitations, mais mon commentaire c'est que j'ai l'impression que ton hébergeur ne sait pas ce qu'il fait niveau sécurité.
Bloquer les fonctions genre rmdir, chgrp, chmod et autre semble etre une tentative de restriction des droits pour éviter qu'un utilisateur n'écrive un peu partout sur le disque. En effet, c'est le seul intéret, puisque cela gène un utilisateur de compte mutualisé.
Seulement le hic, c'est que normalement il n'y a pas besoin de cela si on utilise judicieusement la directive "open_basedir" de php. Ne pas l'utiliser est a mon avis une grave erreur, et si on l'utilise, on a plus besoin de limiter les chown/chmod, etc. Donc au final, je ne vois pas l'interet d'une tel restriction. Bref c'est louche tout ça ! :)
