Y a-t-il un moyen de lire un script php a dis tance ?
20 réponses
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 ?
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 !
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 !
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 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 <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
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
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>
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 <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
Jean-Francois Ortolo
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
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é.
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
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
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.
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:
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
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:
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 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:
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
"Jean-Francois Ortolo" wrote
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.
"Jean-Francois Ortolo" <ortolo.jeanfrancois_nospam@free.fr.invalid> wrote
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.
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 écrivait dans fr.comp.lang.php:
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
Le 02 Mar 2009 15:10:54 GMT, slambert
<slambertNOSPAMPLEASE@vediovis.net> écrivait dans fr.comp.lang.php:
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.
Le 02 Mar 2009 15:10:54 GMT, slambert écrivait dans fr.comp.lang.php:
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
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...
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 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...
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.
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
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:
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 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:
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.
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
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
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.
