Y a-t-il un moyen de lire un script php a dis tance ?

[Jean-Francois Ortolo]

Bonjour

Tout est dans le titre. ;)

Dans le but de sécuriser mon site, j'ai fait ce que j'ai pu ( sans
donner de détails ).

Cependant, ces efforts demeureraient infructueux, s'il y avait une
seule instruction en php ( ou autre language ), capable d'aspirer un
script php avec son texte, sachant que ce script php inclut le script
php qu'il faut cacher.

En effet, le script de départ ( à cacher ) est protégé paru un
fichier .htaccess interdisant qu'on y accède à distance ( "deny from
all" ), ce qui me paraît suffisant pour ce qui est du script lui-même (
dites-moi si je me trompe... )

Mais, ce script doit être inclus dans d'autres scripts php, qui eux
sont accessibles à distance ( obligatoire, ce son tles scripts de mon
site ).

Donc... Est-il possible de télécharger à distance un script php sans
qu'il soit interprété, comme un fihcier texte par exemple ?

Merci beaucoup de vos réponses, grâce auxquelles je saurai si mon
site est sécurisé ou pas.

Bien à vous.

Amicalement.

Jean-François Ortolo

PS Ne pensez-vous pas, que soit le deuxième script est
interprété, auxquel cas le premier script ne sera pas visible comme
texte, soit le deuxième script n'est pas interprété, auquel cas le
premier script ne sera visible que comme un einstruction include ?

[Olivier Miakinen]

Bonjour,

Post by Jean-Francois Ortolo
Tout est dans le titre. ;)

Pas tout, et heureusement... ;-)

Post by Jean-Francois Ortolo
[...] le script de départ ( à cacher ) est protégé paru un
fichier .htaccess interdisant qu'on y accède à distance ( "deny from
all" ), ce qui me paraît suffisant pour ce qui est du script lui-même (
dites-moi si je me trompe... )

Une protection encore meilleure consiste à le mettre dans une partie de
l'arborescence inaccessible au serveur web. Ainsi, même s'il arrivait
que tu écrases le fichier .htaccess par inadvertance, il ne serait
jamais visible.

Post by Jean-Francois Ortolo
Mais, ce script doit être inclus dans d'autres scripts php, qui eux
sont accessibles à distance ( obligatoire, ce sont les scripts de mon
site ).
[...]
PS Ne pensez-vous pas, que soit le deuxième script est
interprété, auxquel cas le premier script ne sera pas visible comme
texte, soit le deuxième script n'est pas interprété, auquel cas le
premier script ne sera visible que comme une instruction include ?

C'est sympa... tu poses la question, puis dans le même article tu donnes
la réponse. C'est exactement ça !

[Patrick Mevzek]

Post by Jean-Francois Ortolo
Merci beaucoup de vos réponses, grâce auxquelles je saurai si mon
site est sécurisé ou pas.

La réponse à votre question est a priori non (sauf erreur grossière de
configuration du serveur web), cependant de là à dire que juste sur
cette fonctionnalité votre site est "sécurisé" c'est un peu rapide.

D'ailleurs il n'y a qu'une seule bonne façon d'être sûr que quelque
chose ne soit pas accessible de l'extérieur (pour ce qui concerne HTTP
ici) : mettre le fichier en question *en dehors* de l'arborescence
servie par le serveur Web.

Les programmes locaux peuvent toujours faire des include, require, etc.
locaux, sans passer par HTTP, et personne ne le pourra à distance si la
ressource n'est pas accessible par HTTP.

[Jean-Francois Ortolo]

Post by Patrick Mevzek
D'ailleurs il n'y a qu'une seule bonne façon d'être sûr que quelque
chose ne soit pas accessible de l'extérieur (pour ce qui concerne HTTP
ici) : mettre le fichier en question *en dehors* de l'arborescence
servie par le serveur Web.
Les programmes locaux peuvent toujours faire des include, require, etc.
locaux, sans passer par HTTP, et personne ne le pourra à distance si la
ressource n'est pas accessible par HTTP.

Bonjour Monsieur

Mais... Ce script à cacher, est inclus dans d'autres scripts php, qui
eux, doivent être accessibles, puisque ce sont des scripts de mon site.

Si quelqu'un fait un include à distance, de l'un de ces scripts
accessibles, ce deuxième script accessible, pourra donc faire un include
en local du script en dehors de l'arbosrescence, et tout le problème est
de savoir s'il existe un moyen de lire le code source du script caché.

Merci beaucoup de vos réponses.

Bien à vous.

Amicalement.

Jean-François Ortolo

[slambert]

Post by Jean-Francois Ortolo
Si quelqu'un fait un include à distance,

Bonjour.

Si quelqu'un fait un include à distance, il incluera le résultat renvoyé par
Apache.

Donc tout repose sur la configuration serveur. Normalement tous les fichiers
sont en .php (n'est ce pas Pascale :) ) et Apache interprète tous les
fichiers en .php.

Sinon, imaginez que l'on puisse appeler à distance les scripts dans le but
de voir leur contenu, ce sera catastrophique.

Bon courage

S.L.

[Denis Beauregard]

Le 02 Mar 2009 15:10:54 GMT, slambert

Post by slambert
Sinon, imaginez que l'on puisse appeler à distance les scripts dans le but
de voir leur contenu, ce sera catastrophique.

Euh, il suffit qu'il y ait une panne de l'interpréteur pour que cela
arrive et personne n'est à l'abri de telles pannes. Je suppose que
c'est plutôt rare, mais quelqu'un pourrait éventuellement faire une
attaque sur un serveur pour faire planter l'interpréteur PHP. Ce
n'est pas pour rien qu'il y a sans cesse de nouvelles versions !

À mon avis, la solution serait, dans ce cas-ci, de placer les
include dans un répertoire protégé par un .htaccess si on n'a pas
la possibilité de les placer en dehors du www du serveur.


Denis

[Bruno Desthuilliers]

Post by Denis Beauregard
Le 02 Mar 2009 15:10:54 GMT, slambert

Post by slambert
Sinon, imaginez que l'on puisse appeler à distance les scripts dans le but
de voir leur contenu, ce sera catastrophique.

Euh, il suffit qu'il y ait une panne de l'interpréteur pour que cela
arrive

J'avoue avoir du mal à voir comment un plantage de l'interpréteur PHP -
qu'il soit déployé comme module apache (le cas le plus courant, de loin)
ou comme CGI - pourrait donner un tel résultat. La conséquence la plus
probable serait un 500, et la pire (si déployé comme module apache) un
plantage d'apache lui-même.

[Denis Beauregard]

Le 03 Mar 2009 10:25:22 GMT, Bruno Desthuilliers

Post by Bruno Desthuilliers

Post by Denis Beauregard
Le 02 Mar 2009 15:10:54 GMT, slambert

Post by slambert
Sinon, imaginez que l'on puisse appeler à distance les scripts dans le but
de voir leur contenu, ce sera catastrophique.

Euh, il suffit qu'il y ait une panne de l'interpréteur pour que cela
arrive

J'avoue avoir du mal à voir comment un plantage de l'interpréteur PHP -
qu'il soit déployé comme module apache (le cas le plus courant, de loin)
ou comme CGI - pourrait donner un tel résultat. La conséquence la plus
probable serait un 500, et la pire (si déployé comme module apache) un
plantage d'apache lui-même.

Une recherche sur google donne ceci :

Résultats 1 - 10 sur un total d'environ 2 320 000 pour php exploit

Il y a donc un grand nombre de possibilités de rupture de sécurité
en PHP.

Je suppose qu'il peut y avoir parmi elles, la possibilité que le
serveur PHP laisse passer le code tel quel, sans l'interptéter.

Mais en fait, la panne la plus simple, c'est si on a mal configuré
le serveur (par exemple lors de l'installation d'une nouvelle
version) et qu'à ce moment, donc pendant un court laps de temps,
les .php sont comme des .html et passent tels quels, sans
interprétation. Cela arrive souvent aux débutants qui essaient
leur code à la maison sans avoir installé de serveur PHP et cela
peut arriver sur un serveur qui ne supporte pas le PHP et où on
installe du code provenant d'un autre serveur sans le tester.


Denis

[slambert]

Post by Denis Beauregard
Résultats 1 - 10 sur un total d'environ 2 320 000 pour php exploit
Il y a donc un grand nombre de possibilités de rupture de sécurité
en PHP.

Je dois dire que ces résultats concernent des exploits pour des applications
écrites en PHP. Cela ne provient pas de la technologie. Modulo un petit
souci réglé dans les 24 heures à l'automne dernier, l'architecture
PHP/Apache elle même est plutôt saine depuis plusieurs années.



Les mauvaises pratiques sont indépendantes du langage et vous retrouverez le
même genre d'erreur de conception dans les autres architectures.

Dans tous les cas concernant le point à l'origine de ce fil de discussion,
le risque repose sur une non interprétation des scripts par le serveur
(mauvaise configuration, plantage, etc...).

Ceci dit, placer tous les fichiers en dehors du répertoire accessible par
Apache, et les appeler via un contrôleur qui vérifiera que tout se basse
bien, c'est une bonne idée. Dans le cas d'un véritable disfonctionnement du
serveur, seul le/les contrôleurs sont accessibles.

MVC rulez, mais c'est une opinion personnelle, et ce uniquement quand le
projet le nécessite (taille, longueur, etc...)

S.L.

[Bruno Desthuilliers]

Post by Denis Beauregard
Le 03 Mar 2009 10:25:22 GMT, Bruno Desthuilliers

Post by Bruno Desthuilliers

Post by Denis Beauregard
Le 02 Mar 2009 15:10:54 GMT, slambert

Post by slambert
Sinon, imaginez que l'on puisse appeler à distance les scripts dans le but
de voir leur contenu, ce sera catastrophique.

Euh, il suffit qu'il y ait une panne de l'interpréteur pour que cela
arrive

J'avoue avoir du mal à voir comment un plantage de l'interpréteur PHP -
qu'il soit déployé comme module apache (le cas le plus courant, de loin)
ou comme CGI - pourrait donner un tel résultat. La conséquence la plus
probable serait un 500, et la pire (si déployé comme module apache) un
plantage d'apache lui-même.

Résultats 1 - 10 sur un total d'environ 2 320 000 pour php exploit
Il y a donc un grand nombre de possibilités de rupture de sécurité
en PHP.
Je suppose qu'il peut y avoir parmi elles, la possibilité que le
serveur PHP laisse passer le code tel quel, sans l'interptéter.

PAQJS, la seule possibilité que cela arrive (sauf faille de sécurité
*dans le code de l'appli elle-même*) serait une erreur de config apache.

Post by Denis Beauregard
Mais en fait, la panne la plus simple, c'est si on a mal configuré
le serveur

Ce qui n'est pas une panne.

Post by Denis Beauregard
(par exemple lors de l'installation d'une nouvelle
version) et qu'à ce moment, donc pendant un court laps de temps,
les .php sont comme des .html et passent tels quels, sans
interprétation. Cela arrive souvent aux débutants qui essaient
leur code à la maison sans avoir installé de serveur PHP et cela
peut arriver sur un serveur qui ne supporte pas le PHP et où on
installe du code provenant d'un autre serveur sans le tester.

Encore une fois, ce sont erreurs humaines, pas une panne logiciel. Rien
à voir avec un "plantage de l'interpréteur PHP".

[Jean-Francois Ortolo]

PS Ne pensez-vous pas, que soit le deuxième script est interprété,
auxquel cas le premier script ne sera pas visible comme texte, soit le
deuxième script n'est pas interprété, auquel cas le premier script ne
sera visible que comme un einstruction include ?

Pour bien faire...

J'ai mis les variables à cacher comme des variables locales dans la
fonction de connexion à la base de données.

Ces variables étant locales à la fonction, elles ne peuvent pas être
accédée à distance, de plus elles sont effacées à la fin de la fonction.

Et puis, le PHP Manual m'indique, que dans le cas où un script fait
un include à distance, il n'est pas possible d'appeler une fonction du
script inclus, localement.

J'ai testé cela, effectivement, et c'est tout à fait exact.

Il reste à savoir, s'il existe ne serait-ce qu'un seule instruction
en php, qui permette d'aspirer le texte d'un script php, sans
l'interpréter, auquel cas ma protection par .htaccess serait le rempart
ultime, puisque je n'ai qu'un hébergement mutualisé, donc pas d'espace
disque non-web.

Merci beaucoup de votre réponse à cette dernière question.

Bien à vous.

Amicalement.

Jean-François Ortolo

[John GALLET]

Bonjour,

Il reste à savoir, s'il existe ne serait-ce qu'un seule instruction en php,
qui permette d'aspirer le texte d'un script php,

Dans le cas d'une attaque distante directe, on se fiche que l'instruction
permettant de récupérer le contenu NON INTERPRETE du fichier aproteger.php
soit en php ou pas. Il y a bien un accès distant, par http, et la question
est donc : est-ce que le serveur web va TOUJOURS renvoyer le RESULTAT et
non pas le fichier.

Il y a alors deux facteurs:

- l'interdiction pure et simple d'accès au fichier par son positionnement
ou l'interdiction d'accès au répertoire.
- la configuration du serveur http

Par exemple, si on met l'instruction:

AddType application/x-httpd-php .html .htm

dans un .htaccess alors les fichiers toto.html et toto.htm seront tous les
deux passés au moteur Zend/PHP avant que le résultat de ce script soit
renvoyé au navigateur.

Donc dès lors que aproteger.ext est bien associé au moteur PHP, on ne
verra jamais le fichier en clair si on le demande par http, mais son
résultat. S'il ne fait que déclarer des constantes, variables et
fonctions, ce sera donc RIEN.

Remarquons au passage que suite à la prolifération de ces #@! de toto.inc
j'ai tendance à ajouter .inc comme extension exécutée par PHP car trop
nombreux sont encore les config.inc qui contiennent des mots de passe.

Noter également que faire :

require('toto.txt');

va bien éxécuter toute instruction PHP contenue dans toto.txt mais si on
demande directement http://......toto.txt il est probable qu'on aura son
texte en clair (et les instructions php aussi).

cas ma protection par .htaccess serait le rempart ultime, puisque je n'ai
qu'un hébergement mutualisé, donc pas d'espace disque non-web.

Là en revanche il peut y avoir un autre type de faille, qui dépend de la
configuration de l'hébergement: qu'un autre script d'un autre
environnement aille lire LOCALEMENT par:
require(../../mon_voisin/www/secret/config.php);
puis fait un vardump ou autre.

Bien entendu, on doit s'en remettre à la qualité de la configuration de
l'hébergement (rootjails, etc.).

Dans un sujet connexe, ceux qui ont 1/2 heure à investir sur un bug de
include et require peuvent lire aussi ceci:

http://www.ush.it/team/ush/hack-phpfs/phpfs_mad.txt

qui peut se résumer en lisant directement le point "VIII) POC and attack
code" à : les listes d'interdiction, on le sait (??) c'est pas bien, on ne
liste pas les actions interdites, on liste les actions autorisées.

a++;
JG

[Jean-Francois Ortolo]

Post by Olivier Miakinen
Bonjour,
Dans un sujet connexe, ceux qui ont 1/2 heure à investir sur un bug de
http://www.ush.it/team/ush/hack-phpfs/phpfs_mad.txt
qui peut se résumer en lisant directement le point "VIII) POC and attack
code" à : les listes d'interdiction, on le sait (??) c'est pas bien, on
ne liste pas les actions interdites, on liste les actions autorisées.

Il me semble, que cette méthode d'attaque, ne pourrait fonctionner
qu'avec un script situé sur le même serveur que celui de mon site.

Effectivement le serveur de mon site a le patch Suhosi, mais encore
faudrait-il, que le hacker prenne le risque, alors que mon hébergeur
veille...

Si le hacker est abonné au même service d'hébergement que moi, Sivit
aura ses coordonnées, le risque est moins grand.

En ce qui me concerne, j'ai testé seulement à distance à l'instant,
et le script php "aspiré" est bien interprété. Mais si le hacker essaye
d'aspirer mon fichier de configuration sans qu'il ne soit interprété, ce
n'est pas un positionnement de ce script hors espace web, qui "fera le
trick". ;)

A priori, le seul critère, serait celui de savoir s'il est possible
d'aspirer le fichier sans qu'il ne soit interprété, *et* en local, pour
bypasser le .htaccess

En fait, mettre le script dans un espace hors web serait une mauvais
idée, si effectivement le hack qu'indique votre lien, fonctionne.

Donc, 1 partout. ;)

Bien à vous.

Jean-François Ortolo

[John GALLET]

Post by John GALLET
http://www.ush.it/team/ush/hack-phpfs/phpfs_mad.txt

Il me semble, que cette méthode d'attaque, ne pourrait fonctionner qu'avec
un script situé sur le même serveur que celui de mon site.

En l'occurence, surtout d'une [ho]|[e]rreur de codage. Ce qui est donné
comme POC c'est que dans le cas où on a (bêtement) utilisé l'algo suivant,
alors on peut passer outre à cause d'un comportement inattendu:

"Si l'extension du fichier est n'importe quoi sauf '.php' alors on peut
exécuter [ceci]"

Mais là pas de pot, l'extension c'est .php/ ou .php/. donc il y a
exécution de [ceci]. Si justement le [ceci] c'est un readfile par exemple,
alors là c'est cuit car on reçoit alors le code de n'importe quel fichier
en clair sans exécution.

C'est une application de "liste noire", liste de choses interdites (ici,
l'extension .php) qui est à la source de la faille avant tout.
Si on avait dit "seules les extensions .html .txt .truc" avec une liste
exhaustive et explicite des extensions autorisées, on n'aurait pas vu le
gag.

Effectivement le serveur de mon site a le patch Suhosi, mais encore
faudrait-il, que le hacker prenne le risque, alors que mon hébergeur
veille...

Qu'il veille, ça ne sert pas à grand chose, il faut surtout qu'il
configure ses rootjails correctement...

Si le hacker est abonné au même service d'hébergement que moi, Sivit aura
ses coordonnées, le risque est moins grand.

Il peut autant y avoir attaque locale suite à compromission d'un autre
site hébergé sur la même machine qu'une attaque délibérée d'un
"colocataire". Seules les barrières mises en place par l'hébergeur pour
que les "colocataires" ne *puissent pas** se voir permettront de s'en
prémunir.

En fait, mettre le script dans un espace hors web serait une mauvais idée,
si effectivement le hack qu'indique votre lien, fonctionne.

Mettre un script en dehors de l'aborescence garanti qu'il ne sera jamais
appelé en direct par http, rien (et moins) de plus.

Dès lors qu'un attaquant arrive à détourner un script pour se balader dans
l'arborescence en lui passant des arguments, ou il exécute du code de
manière incontrôlée si l'injection est faite via require ou include, ou il
lit directement le contenu des fichiers s'il injecte dans readfile ou
passthrough.

a++;
JG

[Jean-Francois Ortolo]

Post by John GALLET
Il peut autant y avoir attaque locale suite à compromission d'un autre
site hébergé sur la même machine qu'une attaque délibérée d'un
"colocataire". Seules les barrières mises en place par l'hébergeur pour
que les "colocataires" ne *puissent pas** se voir permettront de s'en
prémunir.

Ok

Si je comprend bien, je peux toujours tester si ce type d'attaque
fonctionne, en testant moi-même sur mon hébergement en essayant de
charger le source du fichier caché avec l'extension *.php/. à partir
d'un script php ad hoc.

Si l'attaque réussit, je ne peux pas de toute façon savoir, s'il est
possible à un colocataire de lire dans mon arborescence de fichiers, à
moins de le demander à mon hébergeur.

A moins que je n'essaye moi-même de hacker de cette manière un autre
compte, encore faudrait-il que je sache le nom du compte...

Donc, dans l'ensemble, je préfère m'abstenir, et demander à mon
hébergeur si cette possibilité de lecture hors de son espace ftp est
possible, mais là je pense qu'il y a 100% de chances, pour que
l'hébergeur réponde: "non".

...Sinon, je peux toujours vérifier si le mode de php est suphp,
auquel cas, il me suffira de virer les permissions en
lecture/écriture/exxécution, sur autre chose que le propriétaire. ;)

Un coup de phpinfo.php fera l'affaire. ;)

Merci beaucoup de votre aide.

Respectueusement.

Jean-François Ortolo

[Jean-Francois Ortolo]

Post by Jean-Francois Ortolo
...Sinon, je peux toujours vérifier si le mode de php est suphp,
auquel cas, il me suffira de virer les permissions en
lecture/écriture/exxécution, sur autre chose que le propriétaire. ;)
Un coup de phpinfo.php fera l'affaire. ;)

Effectivement

Le phpinfo() indique que deux variables d'environnement $_SERVER['
'] et $_ENV[' '] ( me souviens plus des deux mots exacts ) comportant
le token "SUEXEC_" sont bien positionnées.

Celà confirme ce que je pensais, me souvenant avoir lu quelque part
dans la doc de l'hébergeur de cette nouvelle plate-forme PHP 5 MySQL 5,
que le mode suexec est actif.

Celà est égalemet confirmé par le fait, que j'ai mis les permissions
du script à cacher, à: 700, et le script est encore fonctionnel, ce qui
indique que l'interpréteur php fonction avec le même iud que le
propriétaire du compte ftp.

...Le propriétaire du compte ftp étant d"sormais le seul à pouvoir
accéder à ce script, je n'ai même plus à me poser la question de savoir
si des colocataires peuvent "voir" ce script.

Je pense, qu'en ce qui me concerne, cette constatation clos ma question.

Bien à vous.

Amicalement.

Jean-François Ortolo

[John GALLET]

Re,

Post by Jean-Francois Ortolo
Si je comprend bien, je peux toujours tester si ce type d'attaque
fonctionne, en testant moi-même sur mon hébergement en essayant de charger le
source du fichier caché avec l'extension *.php/. à partir d'un script php ad
hoc.

Je donnais cette faille concernant les include/require de fichier de nom
invalide uniquement parce qu'il est connexe à la notion d'extension
(.truc) pas comme exemple absolu de "l'attaque qui réussit à tous les
coups". Je souhaitais seulement illustrer deux points:

- ne jamais se baser sur l'apparence extérieure d'un fichier pour
déterminer s'il est exécuté ou non (si j'ai un .txt je peux d'une part
configurer apache pour qu'il l'exécute comme un .php et d'autre part
utiliser require/include pour lui faire exécuter le code qu'il contient)

- ne jamais utiliser de listes noires (principe: "on autorise tout sauf"),
uniquement des listes blanches (principe: "on interdit tout sauf").

En l'occurence, du moment qu'on arrive à lire le répertoire du dessus de
son compte et qu'on y voit les colocs, ou à se balader dans l'arborescence
globale de la machine, il n'y a pas les pré-requis d'isolation entre les
différents comptes pour un hébergement "en milieu hostile" (c'est à dire
ouvert à n'importe qui dès lors qu'il paye). Ca peut suffire dans certains
cas, mais pas chez un hébergeur en mutualisé.

On sort ici du cadre de ce forum et des réponses plus appropriées seraient
disponibles sur fcs.

Post by Jean-Francois Ortolo
Donc, dans l'ensemble, je préfère m'abstenir, et demander à mon hébergeur
si cette possibilité de lecture hors de son espace ftp est possible, mais là
je pense qu'il y a 100% de chances, pour que l'hébergeur réponde: "non".

Je dirais plutôt 40% car il y a aussi 60% de chances qu'il ne réponde
jamais ;-)

Petit point au passage sans pub (je n'ai pas d'actions chez eux): quand on
voit que le premier prix du serveur *dédié* chez ovh par exemple c'est
23,91 euros TTC (même mon abonnement de ligne fixe Farce Telecom est plus
cher !) on peut se poser de grosses questions sur l'intérêt de
l'hébergement mutualisé dès lors qu'on a des données un tant soi peu
confidentielles. C'est bien une question d'équilibre, on est d'accord.

a++;
JG

[Pascal PONCET]

Post by Jean-Francois Ortolo
Donc... Est-il possible de télécharger à distance un script php sans
qu'il soit interprété, comme un fichier texte par exemple ?

Bonjour,

Par une autre piste que celles qui ont déjà été données, la réponse peut
être "oui".

J'en veux pour preuve l'audit récent d'un site Web qui a révélé une
faille toute bête (en restant poli) :

Le webmaster a conçu l'appel des images, non pas par une URL variable
classique, du type...

<code>
// page d'accueil "index.php"
<img src="img/<?php echo $img[x] ?>">
</code>

...mais par un script de chargement de fichier !!!

<code>
// page d'accueil "index.php"
<img src="getJpeg.php?url=<?php echo $img[x] ?>">
</code>

<code>
// script "getJpeg.php" (à la racine web)
header("Content-type: image/jpeg");
$url = $_GET["url"];
readfile("img/".$url);
</code>

Dingue, non ?
Avec un navigateur, autre que MSIE (???), il suffit de demander
"http://www.lesite.nul/getJpeg.php?url=../index.php" puis hop, un coup
de "voir source" sur la page blanche de résultat, et on a tout le code
PHP en clair avec les "include" (qu'on peut remonter de la même manière
pour voir les codes d'accès SGBD, etc.).

Donc une vraie catastrophe en terme de sécurité !
Alors, le ".htaccess" ou autre dans tout ça, il faut relativiser.

Cordialement,
Pascal


PS: évidemment, l'adresse du site donnée en exemple est bidon.

[Michael DENIS]

Post by Pascal PONCET
Par une autre piste que celles qui ont déjà été données, la réponse peut
être "oui".
J'en veux pour preuve l'audit récent d'un site Web qui a révélé une
[...]

Très intéressant ! Décidément, les paramètres doivent être scrutés avec
beaucoup de vigilance.

[Bruno Desthuilliers]

Pascal PONCET a écrit :
(snip)

Post by Pascal PONCET
J'en veux pour preuve l'audit récent d'un site Web qui a révélé une
(snip)
<code>
// script "getJpeg.php" (à la racine web)
header("Content-type: image/jpeg");
$url = $_GET["url"];
readfile("img/".$url);
</code>

Mouarfffff !!!!

Post by Pascal PONCET
Dingue, non ?

digne du dailyWTF.

[Jean-Francois Ortolo]

Post by Pascal PONCET
Dingue, non ?
Avec un navigateur, autre que MSIE (???), il suffit de demander
"http://www.lesite.nul/getJpeg.php?url=../index.php" puis hop, un coup
de "voir source" sur la page blanche de résultat, et on a tout le code
PHP en clair avec les "include" (qu'on peut remonter de la même manière
pour voir les codes d'accès SGBD, etc.).
Donc une vraie catastrophe en terme de sécurité !
Alors, le ".htaccess" ou autre dans tout ça, il faut relativiser.
Cordialement,
Pascal

Bonjour Monsieur

C'est sûr, que le readfile en local, et l'envoi direct du contenu du
paramètre $url, constitue un très gros trou de sécurité...

En ce qui me concerne, d'une part mes include sont toujours codés en
dur, et d'autre part, il n'y a pas de readfil dans mes scripts. ;)

En fait, les graphiques automatiques générés sur mon site, viennent
effectivement de contenus rendus avec le header approprié, mais le
contenu, lui, est strictement déterminé par la Course sur laquelle on
est, est comme ce contenu est calculé, il ne correspond pas au contenu
d'un quelconque fichier, déterminable d'une façon ou d'une autre par un
apramètre $_GET, mais ce contenu n'a aucune relation directement
exploitable, avec le paramètre en question, qui détermine le contenu.

De plus, dans mon cas, ce contenu rendu par les graphiques, est
toujours une image, jamais le contenu d'un fichier.

Ce que vous indiquez là, est simplement un très gros trou de
sécurité, que Monsieur Gallet appréciera à a juste valeur... ;)

Bien à vous.

Amicalement.

Jean-François Ortolo