Discussion :

[Neckara]

Bonjour,

Il est possible d'inclure un fichier php distant (dans un serveur distant) dans un autre fichier php (dans un serveur local) grâce à la fonction include.

il doit toujours produire un script PHP valide parce qu'il sera traité sur le serveur local

Le contenu du fichier à inclure sera alors téléchargé puis traité du côté du serveur local.

Or, beaucoup de sites ont des fichiers param.php contenant l'identifiant et le mot de passe pour la base de données.
Il suffit alors d'inclure ce fichier param.php pour récupérer le mot de passe et le login.

Heureusement, on peut modifier des options d'Apache pour interdire ces inclusions.
Mais pour des raisons X ou Y, on peut vouloir que certains fichiers soient inclus et pas d'autres ou l'hébergeur ne nous permet pas de modifier la configuration d'Apache et il n'a pas interdit les inclusions du fichier à distance.


J'aimerai donc savoir s'il existe un moyen d'interdire cette inclusion dans le fichier même.

Lors de l'inclusion du fichier, le serveur distant va devoir lire le contenu du fichier php pour pouvoir l'envoyer au serveur local, dans ce cas là, existe-t-il un mot clé pour lui signifier qu'il ne doit pas envoyer le contenu au serveur local ?

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
<?php
$mdp = "";
fonction_machin(); //ce qui se trouve ci-dessous ne devra pas être envoyé
$mdp = "toto";
fonction_finMachin(); //ce qui se trouve ci-dessous pourra être envoyé
echo $mdp;

[Invité]

Bonjour,
Petite confusion dans ta vision des choses:
Quelque soit ton include, tu ne recevra que "le html resultant" renvoyé par le php qui ne peut-étre interprété que sur son serveur !

C'est toute la différence et elle est de taille entre un include siteA/siteA
et siteB/siteA !!
Cokkies différents session differentes par d'interprétation etc...
JE REEDITES pour te préciser qu'un bon PHP prevu pour un include devrait contrôler le php appelant
exemple dans tout mes php principaux je mets

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<?php
$pourvoir="xx";
include("mesincludes/uninclude.php");
?>

Et dans uninclude.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<?php
if (!isset($pourvoir))
 {
echo '<meta http-equiv="refresh" content="0;URL=http://www.monsite.com/index.php">';
 exit();
 }
?>

[Gugelhupf]

Bonjour,

Houla, j'ai l'impression que vous vous compliquez la vie.
Déjà la première chose à faire c'est de ne jamais laisser ses identifiants et mots de passe trainer sur les fichiers de son serveur, cela évite de se faire avoir au niveau du FTP dans un premier temps.

Ensuite oui il peut être dangereux de laisser l'utilisateur prendre contrôle de l'include.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<?php
include($_GET['bidule']); // Exemple basique représentant un danger

Ne jamais l'utilisateur se servir de ce genre de faille, il risque d'entrer la valeur qu'il veut via son URL.
Solution : Utilisez les include à votre avantage, mettez-y des constantes, ou des variables que vous générez-vous même.

[Invité]

Bonjour a toi,
C'est je penses le manque de pratique qui te fais répondre cela, en effet, tu les mets ou toi tes login MySql

Pour ton autre intervention, impossible de comprendre ce don tu parles
qui t'a parlé d'un GET etc...

Il vaut mieux ne pas intervenir lorsque nous ne maîtrisons pas une question !
Merci a toi d'en tenir compte.
Christele

[Neckara]

Bonjour,
Petite confusion dans ta vision des choses:
Quelque soit ton include, tu ne recevra que "le html resultant" renvoyé par le php qui ne peut-étre interprété que sur son serveur !

En effet, j'ai eu une petite confusion en lisant 2/3 trucs sur les failles du php.
J'avais lu qu'ils faisaient exécuté des scripts php du côté du serveur distant avec un include.
Mais après relecture, j'ai vu ils utilisent des fichiers avec une extension .txt, un serveur ftp avec accès anonyme ou un serveur n'exécutant pas le php.
Je suis passé dessus un peu trop vite

Donc comme sur mon serveur, aucune de ces conditions ne sera respectée, mes fichiers php ne pourront pas être interprété ailleurs que sur mon serveur.

Merci pour votre réponse

EDIT : @Gugelhupf : Tu es HS, je ne parle pas du hacker qui souhaite exécuter son fichier php du côté du serveur mais qui souhaiterait obtenir des informations d'une page php du serveur en l'incluant dans sa propre page php.
Mais vu que seul le code HTML sera envoyé, on ne risque rien.

[Gugelhupf]

Salut Christele (content de te retrouver ici ),

C'est je penses le manque de pratique qui te fais répondre cela, en effet, tu les mets ou toi tes login MySql

Mes logins et mots de passes sont situés dans un fichier de configuration parameters.ini

[Invité]

Mes logins et mots de passes sont situés dans un fichier de configuration parameters.ini

Ah oui que le visiteur ne peut donc pas lire, alors qu'il pourait lire parameters.php par exemple.
Tu plaisantes l'Ami.

[Gugelhupf]

Non du tout, j'utilise un framework, cette partie n'est pas accessible au public
Utiliser un framework diminue les chances de tomber sur différents types de pièges.
Si vous n'utilisez pas de framework je vous conseille entre CakePHP, Symfony, CodeIgniter et Zend (les plus connus/utilisés en faite ).

[Invité]

Decidément mieux vaut en rester là
Tu ne savais pas que tu peux sur un site fait entiérement par toi,
obtenir la même chose

[Gugelhupf]

Bien sur que je peux construire un site en PHP pure (d'ailleurs bonne chance à celui qui ne connait pas assez bien le langage pour se lancer dans un framework), mais pourquoi réinventer la roue ?
Grâce aux framework on a une meilleure organisation, tout est mieux cadré.

[Neckara]

C'est vrai que l'utilisation d'un fichier en .ini est vraiment plus sécurisé qu'un fichier php...

Si l'hébergeur n'accepte pas les .htaccess ou s'il y a une erreur/oublie dans ton fichier .htaccess, tu te retrouve avec tous tes mots de passe/logins visible par n'importe qui...

pourquoi réinventer la roue ?

Parce que la roue ne répond pas à nos besoins et attentes.
J'avais un site fait sur une base de nukled klan, pourquoi alors essayer de le refaire à partir de 0 ?
Tout simplement parce que le code est horrible, non commenté et non documenté et qu'il est très difficile de se retrouver dedans.
De plus il nécessite plus d'une semaine pour pouvoir s'habituer pour pouvoir commencer à travailler dessus.
C'est aussi une véritable usine à gaz dont la majorité des fonctionnalités ne nous conviennent pas.

Dès lors il est préférable, de refaire la roue dans une version plus light, plus propre, plus intuitive et documentée facilitant ainsi toutes les modifications.


Je n'ai rien contre l'utilisation des framework, mais ce n'est pas moi qui code le site, je n'ai pas beaucoup de temps et je doit donc déléguer certaines tâches dont la réalisation du site.
Or, la personne qui s'occupe du site peut très bien partir du jour au lendemain.
Il est alors beaucoup plus difficile de retrouver une personne connaissant le même framework et pouvant travailler directement sur le site sans à avoir à passer par une phase d'apprentissage du framework utilisé.

Je n'ai pas la prétention de bien m'y connaitre en programmation php, j'ai eu 7 semaines de cours pour faire HTML/CSS/PHP à raison de 2h de cours + 2h de TP par semaine.
Je n'ai d'ailleurs jamais eu l'occasion d'utiliser de framework, il est clair qu'on ne peut pas tout savoir.

Après, je ne suis pas obtu et j'essayerais d'en parler avec la personne qui travaille sur mon site, mais je ne suis pas sûr qu'utiliser un framework soit intéressant dans cette situation-ci.

[Gugelhupf]

C'est vrai que l'utilisation d'un fichier en .ini est vraiment plus sécurisé qu'un fichier php...

Quel est le rapport ? Le .ini est un fichier de configuration texte je suis d'accord, mais il est placé sous la structure d'un framework, donc include ou pas vous ne pouvez y accéder de l'extérieur. Aussi vous faite référence à Apache et .htaccess (Deny from all), mais quel est le rapport ?
Je parle de framework, pensez-vous que l'architecture des frameworks soient tous dépendants d'Apache ou adaptable à Nginx, IIS, Google Web Server etc... ?

De plus il nécessite plus d'une semaine pour pouvoir s'habituer pour pouvoir commencer à travailler dessus.

Un framework nécessite encore plus de temps, mais les professionnels (ou les SSII plutôt) n'ont pas l'habitude d'engager quelqu'un sans expérience.

J'avais un site fait sur une base de nukled klan

Il m'ait peut-être arrivé de voir une ou deux fois grand max ce nom sur des forums, mais ce n'est pas un framework, c'est un CMS.

Il est alors beaucoup plus difficile de retrouver une personne connaissant le même framework et pouvant travailler directement sur le site sans à avoir à passer par une phase d'apprentissage du framework utilisé.

Je ne sais pas si vous travaillez dans le domaine professionnel ou semi-professionnel, mais aujourd'hui on apprend les framework pour que justement tout le monde utilise les mêmes conventions, les mêmes méthodes.
De plus, comme je vous ai déjà cité les 4 frameworks les plus connus, vous avez de grandes chances qu'un développeur en connaisse un et maitrise l'outil s'il a de l'expérience sur le marché.

[Neckara]

Le .ini est un fichier de configuration texte je suis d'accord, mais il est placé sous la structure d'un framework, donc include ou pas vous ne pouvez y accéder de l'extérieur.

J'ai du mal à comprendre, le .ini est bien mis côté serveur ?
Dans ce cas là, comment le framework ferait-il pour empêcher sa lecture ?

vous avez de grandes chances qu'un développeur en connaisse un et maitrise l'outil s'il a de l'expérience sur le marché.

On se place dans le domaine amateur (pas de rémunération).
Sinon je concède qu'en entreprise les frameworks sont plus qu'intéressantes.

[RunCodePhp]

J'ai du mal à comprendre, le .ini est bien mis côté serveur ?
Dans ce cas là, comment le framework ferait-il pour empêcher sa lecture ?

C'est théoriquement très simple à comprendre, et le principe à la base n'est même pas lié à un FrameWork.

Quand on crée un site Web, tous les fichiers sont normalement sur le serveur, quelque soit le type de fichier (ini, .htaccess, php, png, etc ...).
Lorsqu'on fait un include, ça ne fait que inclure, donc en aucun cas cela va renvoyer le contenu du fichier.
Pour cela il faut faire un echo (ou print), donc un code Php pour ça.

Le simple fait d'utiliser un fichier INI, et bien même si on venait à laisser trainer un echo $password (genre à un moment de débug) cela va rien renvoyer non plus car un fichier INI ne sera pas interprété par Php, alors que si on faisait la même étourderie cela renverrait sa valeur, et donc pourra être lu.

De plus, et sauf erreur, les hébergeurs rajoute une protection sur certain types de fichiers, comme les .ht_* et .INI de façon que les contenu ne puissent être renvoyés.

Vient encore un autre aspect, la manière de structurer un site Web.
Normalement il est bon de mettre dans le vhost (virtualhost, qui souvent se nomme www, ou public_html, ...) uniquement les fichiers devant être atteint par une URL.
Comme pour les images (png, jpg, ...), les CSS, JS.
Tout le reste devraient se trouver en dehors du vhost, ce qui fait qu'il est théoriquement impossible d'atteindre tous ces fichiers.
En tout cas le minimum est de le faire pour les fichiers contenant des identifications (Bdd, etc ...).

En général les FrameWork sont conçus pour qu'ils installent de cette manière là, permettent aussi de faire de la réécriture d'URL, et comme seul et unique fichier dans le vhost (à part les img, css, js, ...) un fichier Php comme point d'entré, en général index.php.
Tout le système (tous les autres fichiers, php, ini, ...) sont inaccessibles via une URL.
La protection se trouve donc naturellement dans la manière de structurer/concevoir le site Web.
Sans compter qu'on est jamais assez prudent, on rajoute en plus un .htaccess là où se trouve tout le système avec un "deny from all" quand bien même tout ceci soit théoriquement déjà "verrouillé par l'hébergeur.

Tout ceci est juste un seul aspect concernant la sécurité à prendre en compte, il y en a bien d'autres encore.

Pas sûr que certains amateurs savent se genres de choses, et si leur sites viennent à avoir une certaine notoriété, et bien c'est en général à ce moment où les problèmes commencent.
Les actes ou tentatives de piratages sont en général proportionnels à cette notoriété, mais aussi de son intérêt (de l'argent à gagner directement ou indirectement).

Si le site est quasi inconnu, susciterait quasi aucun intérêt, il n'y a peut être lieu de prendre toutes ces protections.

[Neckara]

Le simple fait d'utiliser un fichier INI, et bien même si on venait à laisser trainer un echo $password (genre à un moment de débug) cela va rien renvoyer non plus car un fichier INI ne sera pas interprété par Php, alors que si on faisait la même étourderie cela renverrait sa valeur, et donc pourra être lu.

Un fichier param.php ne contiendra jamais d'instruction, juste des variables et leurs valeurs. Pour consulter la valeur, il suffit de regarder le code source.
Qu'on lise la valeur du password à partir d'un fichier .php ou .ini, dans les deux cas, si dans le fichier incluant on fait un echo $password, le password sera affiché. Je ne vois donc pas très bien la différence.

De plus, et sauf erreur, les hébergeurs rajoute une protection sur certain types de fichiers, comme les .ht_* et .INI de façon que les contenu ne puissent être renvoyés.

Ce n'est pas le cas de tous les hébergeurs (en l'occurrence pas le mien).
Ainsi dans le cas d'une migration, il faudra d'abord tester si les .INI sont visible ou non. Sans compter que l'hébergeur peut très bien pour des raisons X ou Y modifier ses configurations et ainsi faire afficher les fichiers .INI (on ne sait jamais, une erreur ou autre)

Vient encore un autre aspect, la manière de structurer un site Web.
Normalement il est bon de mettre dans le vhost (virtualhost, qui souvent se nomme www, ou public_html, ...) uniquement les fichiers devant être atteint par une URL.
Comme pour les images (png, jpg, ...), les CSS, JS.
Tout le reste devraient se trouver en dehors du vhost, ce qui fait qu'il est théoriquement impossible d'atteindre tous ces fichiers.
En tout cas le minimum est de le faire pour les fichiers contenant des identifications (Bdd, etc ...).

Le problème c'est que généralement, les hébergeurs ne nous permettent pas de mettre des fichiers ailleurs que dans le vhost.

un fichier Php comme point d'entré, en général index.php.

ça empêche de voir le contenu du dossier.
J'ai des amis qui ont réussi par hasard à trouver un zip de toutes les sources du site du C2I à cause de l'absence d'un tel fichier...
Mais c'est largement insuffisant pour garantir une certaine sécurité.

Sans compter qu'on est jamais assez prudent, on rajoute en plus un .htaccess là où se trouve tout le système avec un "deny from all" quand bien même tout ceci soit théoriquement déjà "verrouillé par l'hébergeur.

Mais ça dépend encore une fois de l'hébergeur, ils ne prennent pas tous en compte les htaccess.

Si le site est quasi inconnu, susciterait quasi aucun intérêt, il n'y a peut être lieu de prendre toutes ces protections.

Certes, mais autant corriger certaines failles dès qu'on s'aperçoit de leur existence^^


Je pense donc qu'on peut utiliser le fichier ini quand on a son serveur dédié, mais si on se fait héberger son site internet, il est plus pratique d'utiliser un fichier param.php ce qui permettra de changer d'hébergeur plus facilement et sans risque.

[Gugelhupf]

Vous vous embêtez avec le fichier .ini, c'était à titre d'exemple, pour dire que je ne stocke pas mes login/mdp dans un fichier PHP.
Déjà dans un premier temps il faudrait que l'utilisateur puisse atteindre ce fichier .ini, comment feriez-vous pour atteindre un tel fichier ?
Vous vous focalisez sur Apache et .htaccess, il ne faut pas rendre trop dépendant le serveur HTTP avec l'application PHP (pour une migration par exemple). Exemple: Si je vous dis URL Rewriting vous me répondrez IfModule etc... alors qu'il est aussi possible de le simuler via PHP.

[RunCodePhp]

Qu'on lise la valeur du password à partir d'un fichier .php ou .ini, dans les deux cas, si dans le fichier incluant on fait un echo $password, le password sera affiché. Je ne vois donc pas très bien la différence.

C'est bien ce que j'ai dit, faire un echo $password est soit une étouderie (pour l'amateur) soit une faute grave de la part du codeur professionnel.
Ce n'est compliqué à comprendre, non ?

Ce n'est pas le cas de tous les hébergeurs (en l'occurrence pas le mien).

Alors si tu veux une sécurité accrue, alors faudrait peut être envisager de changer d'hébergeur, ou opter pour du dédié, ce qui permet plus de liberté à ce niveau (et bien d'autres).

Ainsi dans le cas d'une migration, il faudra d'abord tester si les .INI sont visible ou non. Sans compter que l'hébergeur peut très bien pour des raisons X ou Y modifier ses configurations et ainsi faire afficher les fichiers .INI (on ne sait jamais, une erreur ou autre)

Tout ça relève de incompétence.
Mais j'ai idée que ça ne doit pas arrivé tous les 4 matins.
Si tu est aussi parano que ça, alors faudrait non pas opter pour un serveur dédié, mais héberger toi même ton propre site Web et par conséquent gérer tout ces aspect de la sécurité de A à Z.

Le problème c'est que généralement, les hébergeurs ne nous permettent pas de mettre des fichiers ailleurs que dans le vhost.

Il y a même pas 2 ou 3 moi de ça j'ai crée un site Web sur un hébergeur 100% gratuit, et il permet de le faire.
En plus de ça j'exploite depuis très longtemps un autre hébergeur payant (plus pro cette fois) lui aussi permet de le faire.
Là encore il y a peut être un problème du choix de l'hébergeur.

ça empêche de voir le contenu du dossier.

Tu n'a pas compris le principe que j'ai expliqué.
Je te parle que 100% du site passe par un seul et unique fichier index.php qui lui fait office de point d'entrée pour absolument tout le site Web.
Ceci n'a strictement rien à voir avec ce que tu évoque qui d’ailleurs ne sert à rien car ceci peu se gérer en une seule ligne dans le .htaccess.

Je pense donc qu'on peut utiliser le fichier ini quand on a son serveur dédié, mais si on se fait héberger son site internet, il est plus pratique d'utiliser un fichier param.php ce qui permettra de changer d'hébergeur plus facilement et sans risque.

Faudrait savoir.
Soit tu souhaites une sécurité un peu plus accrue, dans telle cas utiliser un INI va dans se sens, soit tu penses qu'il n'est pas utile de pousser aussi loin, donc de privilégier la simplicité.
Quelque soit la réponse ça n'a rien avoir avec une formulaire mutualisée ou dédiée.
Il existe des hébergeurs qui proposent des formules mutualisées très pros, les tarifs frisent ceux des dédies voir même au-delà.

[Invité]

Bonsoir,
Je ne peux laisser se dérouler ce type de dialogue sans remettre les choses en place.

Si j'essais de lire un fichier xx.toto ou xxx.jpg ou xxx.ini s'il sagit d'un fichier texte j'en lirais tout le texte ! et donc tout mots de passe ou autre donnée confidentielle.

Si j'essais de lire un fichier xxx.php je n'obtiendrais que ses echos ... donc un
$monMDP="xxx123"; sera invisible

J'espéres que vous comprendrez ce minimum vital !

En prime je vous rappelles que le php qui utiliserais ce fichier devrait étre piraté également pour qur le hackeur sache que les données sensibles sont dans /xxxxxxx/yyyyyy/xxx123.php A méditer aussi

[Neckara]

Soit tu souhaites une sécurité un peu plus accrue, dans telle cas utiliser un INI va dans se sens

La seule faille à l'utilisation d'un fichier param.php serait de laisser un echo $password dedans ce qui est plus qu'improbable vu qu'on testera plutôt l'echo $password dans le fichier incluant ce qui aboutira au même résultat que le fichier inclut soit un .php ou un .ini


On pourra certes atteindre le fichier param.php mais seul le contenu HTML sera envoyé, c'est à dire rien.

Mais l'avantage du fichier param.php c'est qu'il pourra être utilisé même sur les petits hébergeurs qui ne proposent pas tout ce qui est nécessaire à l'emploi d'un fichier .ini

Existerait-il une autre faille à l'utilisation d'un fichier param.php ?

[rawsrc]

Bonjour,

pour utiliser un fichier .php afin d'y stocker los paramètres sensibles, voici une astuce qui offre un niveau de sécurité en béton :
- il suffit de commenter le contenu de votre fichier param.ini.php :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
/*

[db]
scheme = mysql
host = localhost
port = 3306
database = test
user = root
pwd = root
attempts = 3
timeout = 5

*/
?>

De cette manière même s'il y un écho qui traîne il ne sera pas interprété, sans compter que cette astuce ne gêne en rien le parseur parse_ini_file() de php
Et si pour n'importe quelle raison, quelqu'un tombe dessus, il n'a aucun moyen de voir le contenu du fichier dans la mesure où le PHP ignore dans tous les cas les commentaires.