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

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


A bientot

--
Marc

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
>
>
> A bientot

bretz a écrit :
> Existe-t-il un moyen de découvrir à priori les fonctions bloquéespar
> les hébergheurs ?

Leur demander ?

Spyou wrote:
> bretz a écrit :
>> 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

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/

bretz a écrit :
> Existe-t-il un moyen de découvrir à priori les fonctions bloquées par
> les hébergheurs ?
Regarder le phpinfo généralement fournit ?
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
** Spécialiste Logiciels Libres **

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.

--
Eric Demeester - http://www.galacsys.net