À lire et à appliquer:
http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite>
La seule solution fiable est de ne jamais utiliser des lignes de code du
type <? include $quelquechose ?>, dès lors que la variable $quelquechose
dépend des champs de la requête HTTP GET ou POST.
</cite>
imagine le programmateur viré qui s'est laissé une porte d'entrée dans le serveur, dans un répertoire archi-caché, on va dire pour simplifier les choses, sur la racine qui se trouve 3 répertoire en amont :
monsite?include=../../../back-door
ta vérification va n'y voir que tu feu
note bien que si ce genre de truc fonctionne sur ton serveur, tu mérites de n'y voir que du feu... Tu ne devrais pas pouvoir inclure de fichiers en amont, et encore moins en dehors de DocumentRoot.
Pas d'accord, et même partisan du contraire. DocumentRoot est la racine d'une arborescence de documents destinés à être "servis" à un internaute en cas de requête. Les include, dans la plupart des cas, n'ont pas vocation à être 'appelés' seuls. (contre-exemple : un fichier 'commun.php' et des fichiers specialises qui ne font que prédéfinir des paramètres pour éviter à l'internaute d'appeler des trucs du style commun.php?ping=pong&pong=ping. Un tennis.php qui fait $ping='pong' ... puis include'commun.php' a alors un sens). Donc en général, à mon sens, les fichiers include DOIVENT être en dehors de l'arborescence DocumentRoot. Et la directive include_path de php.ini est apparemment là pour cela.
pierre-jean
ps: merci à foodbyfood pour son exemple. J'ai cependant quelques doutes sur son caractère autre que théorique. Si un programmeur fait cela, en cas de découverte de 'back-door' il risque de gros problèmes même s'il ne l'a pas utilisé. Et s'il est dans une situation où il peut être à peu près sûr que 'back-door' ne sera pas trouvé, alors il n'a probablement pas besoin de recourir à 'serveur web/php' pour activer sa back-door.
"patpro" <patpro.pouet@archange.fr> a écrit dans le message news:
patpro.pouet-2D8325.09541318092003@news.wanadoo.fr...
In article <a98fea6a.0309171021.11302b88@posting.google.com>,
foodbyfood@hotmail.com (FoodByFood) wrote:
imagine le programmateur viré qui s'est laissé une porte d'entrée dans
le serveur, dans un répertoire archi-caché, on va dire pour simplifier
les choses, sur la racine qui se trouve 3 répertoire en amont :
monsite?include=../../../back-door
ta vérification va n'y voir que tu feu
note bien que si ce genre de truc fonctionne sur ton serveur, tu mérites
de n'y voir que du feu...
Tu ne devrais pas pouvoir inclure de fichiers en amont, et encore moins
en dehors de DocumentRoot.
Pas d'accord, et même partisan du contraire.
DocumentRoot est la racine d'une arborescence de documents destinés à être
"servis" à un internaute en cas de requête.
Les include, dans la plupart des cas, n'ont pas vocation à être 'appelés'
seuls.
(contre-exemple : un fichier 'commun.php' et des fichiers specialises qui ne
font que prédéfinir des paramètres pour éviter à l'internaute d'appeler des
trucs du style commun.php?ping=pong&pong=ping.
Un tennis.php qui fait $ping='pong' ... puis include'commun.php' a alors un
sens).
Donc en général, à mon sens, les fichiers include DOIVENT être en dehors de
l'arborescence DocumentRoot.
Et la directive include_path de php.ini est apparemment là pour cela.
pierre-jean
ps: merci à foodbyfood pour son exemple. J'ai cependant quelques doutes sur
son caractère autre que théorique. Si un programmeur fait cela, en cas de
découverte de 'back-door' il risque de gros problèmes même s'il ne l'a pas
utilisé. Et s'il est dans une situation où il peut être à peu près sûr que
'back-door' ne sera pas trouvé, alors il n'a probablement pas besoin de
recourir à 'serveur web/php' pour activer sa back-door.
imagine le programmateur viré qui s'est laissé une porte d'entrée dans le serveur, dans un répertoire archi-caché, on va dire pour simplifier les choses, sur la racine qui se trouve 3 répertoire en amont :
monsite?include=../../../back-door
ta vérification va n'y voir que tu feu
note bien que si ce genre de truc fonctionne sur ton serveur, tu mérites de n'y voir que du feu... Tu ne devrais pas pouvoir inclure de fichiers en amont, et encore moins en dehors de DocumentRoot.
Pas d'accord, et même partisan du contraire. DocumentRoot est la racine d'une arborescence de documents destinés à être "servis" à un internaute en cas de requête. Les include, dans la plupart des cas, n'ont pas vocation à être 'appelés' seuls. (contre-exemple : un fichier 'commun.php' et des fichiers specialises qui ne font que prédéfinir des paramètres pour éviter à l'internaute d'appeler des trucs du style commun.php?ping=pong&pong=ping. Un tennis.php qui fait $ping='pong' ... puis include'commun.php' a alors un sens). Donc en général, à mon sens, les fichiers include DOIVENT être en dehors de l'arborescence DocumentRoot. Et la directive include_path de php.ini est apparemment là pour cela.
pierre-jean
ps: merci à foodbyfood pour son exemple. J'ai cependant quelques doutes sur son caractère autre que théorique. Si un programmeur fait cela, en cas de découverte de 'back-door' il risque de gros problèmes même s'il ne l'a pas utilisé. Et s'il est dans une situation où il peut être à peu près sûr que 'back-door' ne sera pas trouvé, alors il n'a probablement pas besoin de recourir à 'serveur web/php' pour activer sa back-door.
Michel BILLAUD
"Lionel" writes:
Steph wrote:
Bonjour,
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
heu...ca parait évident, non ?
je me pose néanmoins une question quand je lis ce genre de choses: comment une personne mal intentionnée peut elle connaitre le nom de la variable $quelquechose ? (si le site n'est pas basé sur un projet opensource)
Parfois, en cherchat mapage.php~ ....
-- Michel BILLAUD LABRI-Universite Bordeaux I phone W: 05 4000 6922 / 05 4000 5792 351, cours de la Liberation http://www.labri.fr/~billaud 33405 Talence (FRANCE) http://dept-info.labri.fr/~billaud
"Lionel" <cooll_nospam@free.fr> writes:
Steph wrote:
Bonjour,
À lire et à appliquer:
http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite>
La seule solution fiable est de ne jamais utiliser des lignes de code
du type <? include $quelquechose ?>, dès lors que la variable
$quelquechose dépend des champs de la requête HTTP GET ou POST.
</cite>
heu...ca parait évident, non ?
je me pose néanmoins une question quand je lis ce genre de choses: comment
une personne mal intentionnée peut elle connaitre le nom de la variable
$quelquechose ? (si le site n'est pas basé sur un projet opensource)
Parfois, en cherchat mapage.php~ ....
--
Michel BILLAUD billaud@labri.fr
LABRI-Universite Bordeaux I phone W: 05 4000 6922 / 05 4000 5792
351, cours de la Liberation http://www.labri.fr/~billaud
33405 Talence (FRANCE) http://dept-info.labri.fr/~billaud
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
heu...ca parait évident, non ?
je me pose néanmoins une question quand je lis ce genre de choses: comment une personne mal intentionnée peut elle connaitre le nom de la variable $quelquechose ? (si le site n'est pas basé sur un projet opensource)
Parfois, en cherchat mapage.php~ ....
-- Michel BILLAUD LABRI-Universite Bordeaux I phone W: 05 4000 6922 / 05 4000 5792 351, cours de la Liberation http://www.labri.fr/~billaud 33405 Talence (FRANCE) http://dept-info.labri.fr/~billaud
