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

Le
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 ?
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
Olivier Miakinen
Le #18799381
Bonjour,

Le 01/03/2009 23:41, Jean-Francois Ortolo a écrit :

Tout est dans le titre. ;)



Pas tout, et heureusement... ;-)

[...] 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.

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
Le #18799391
Le Sun, 01 Mar 2009 22:41:47 +0000, Jean-Francois Ortolo a écrit:
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.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
Jean-Francois Ortolo
Le #18800311
Patrick Mevzek a écrit :

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
Jean-Francois Ortolo
Le #18800321
Jean-Francois Ortolo a écrit :

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
Le #18803401
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
slambert
Le #18803951
"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 #18807501
Le 02 Mar 2009 15:10:54 GMT, 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
Pascal PONCET
Le #18807511
Jean-Francois Ortolo a écrit :
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"
</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.
Jean-Francois Ortolo
Le #18807521
John GALLET a écrit :
Bonjour,

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.




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
Michael DENIS
Le #18810051
Pascal PONCET a écrit :
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) :
[...]



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

--
Michaël DENIS
Publicité
Poster une réponse
Anonyme