PHP - Sécurité - inclusion et fichier .inc

Tyim · Le 29/05/2007, à 23:01

Salut.

J'ai créé un site web avec un index.php et des contenus.inc

Mon site était d'abord sur un serveur distant UNIX.
J'avais donc mis les droits 700 et il n'y avait pas de problèmes, car à distance on ne pouvait pas ouvrir mes fichiers .inc.

Aujourd'hui, le site a migré sur online.net.
Et si on tapes monsite/includes , on voit la liste des fichiers .inc, et on peut les ouvrir et lire le code PHP.

Qu'est que je dois faire pour interdire l'ouverture et la lecture des fichiers .inc ??

C'est très grave car on peut également lire mon fichier de connection à la base de données.

Merci pour vos réponses, je bloque.

marc31 · Le 30/05/2007, à 06:55

il te faut renommer ces fichiers :
- nom-fichier.php
- mon-fichier-inc.php

ou quelque chose en .php

Tyim · Le 30/05/2007, à 09:10

oui, ça marcherait, mais ça change un peu tout car il faut que j'ajoute du code dans chaque fichier pour qu'ils ne s'ouvrent pas en dehors de l'index.php.

Si je renomme mon fichier en monfichier.inc.php, le serveur de l'hebergeur comprend t'il par défaut qu'il ne faut pas l'ouvrir seul ?

J'ai lu qu'il y avait une possibilité de paramétrer le serveur pour interdire la lecture de fichier.
Mais comme je suis avec online.net, je n'ai pas accès au php.ini.
Il y a peut être un fichier que je peux ajouter pour modifier certains paramètres serveur.

Dernière modification par Tyim (Le 30/05/2007, à 09:12)

Tonio · Le 30/05/2007, à 09:37

Mets un .htaccess dans ton includes, qui contient

Deny From All

Ca devrais jouer.

marc31 · Le 30/05/2007, à 09:53

sauf si index.php est aussi dans le meme dossier, sinon pourquoi pas.

pour info, les fichiers inclus ne devraient pas contenir de code, mais juste des déclarations de fonctions ou de classes. Ce qui fait que l'ouverture (avec navigateur, en imaginant un hypothétique petit curieux) ne provoque rien : aucune execution de code, donc une page blanche et pas d'actions sur la base de données ou les fichiers.

il doit y avoir un probleme de conception sur ton site

inazo · Le 30/05/2007, à 11:39

Salut à tous,

Un script php doit toujours au grand toujours se finir par .php ou à la rigueur .php3 ou .php4 ou .php5

Si ce n'est pas le cas c'est un désastre de sécurité. C'est en plus ma faille préféré pour récolter des information facilement.

Mais une chose qui touche beaucoup les développeurs Linux c'est quand on envoi nos fichier sur les ftp et que l'on y oubli un fichier de sauvegarde comme connexionbdd.php~ cela à le même effet dévastateur.

Cordialement Inazo.

Psykotik · Le 30/05/2007, à 12:09

inazo a écrit :

Salut à tous,
Un script php doit toujours au grand toujours se finir par .php ou à la rigueur .php3 ou .php4 ou .php5
Si ce n'est pas le cas c'est un désastre de sécurité. C'est en plus ma faille préféré pour récolter des information facilement.

Je serais curieux de savoir comment est-ce que tu réussis à obtenir le nom du fichier ne se terminant pas par .php... Même si le contenu du fichier apparaît en clair, le fichier php d'origine (contenant) a pour nom obligatoirement php, et les includes sur les php appelés (contenus) sont invisibles au surfeur.

Tyim · Le 30/05/2007, à 13:14

En fait au départ j'avais bien créé des fichiers en .PHP

Si ce n'est pas le cas c'est un désastre de sécurité. C'est en plus ma faille préféré pour récolter des information facilement.

Et puis comme j'étais sur un seveur UNIX, et que mes fichiers étaient avec les droits 700, j'ai choisis de donner une autre extention que .php
Je trouvais la solution beaucoup plus adéquat. Car seul le serveur pouvait les lire. et donc impossible de lire le contenu par un accès extérieur.

Et tu vois pour le fait de connaitre la faille, je l'ai testé avant de mettre en ligne.

Ce n'est pas non plus en .inc que j'ai renommé les fichiers, mais c'est le même résultat.

Je connais très bien la solution en .inc.php, et aprés on y met du code pour sécuriser. mais je veux voir si il n'y a pas une autre solution.
(on est pas obligé de prendre pour content ce qui se fait. On peut chercher de nouvelles méthodes ou existantes mais hors de mes connaissances)

Même si le contenu du fichier apparaît en clair, le fichier php d'origine (contenant) a pour nom obligatoirement php, et les includes sur les php appelés (contenus) sont invisibles au surfeur.

Même avec des contenus.inc.php et le index.php. Le petit malin peut toujours réussir à trouver le chemin en tapant htpp://www.monsitevictime.fr/contenus.inc.php
Donc ça ne résout pas mon problème. Ensuite, je peux effectivement renommer mes fichiers en .inc.php et ajouter à bout de code dans chaque fichier pour empêcher quiconque de l'ouvrir en dehors de sont 'conteneur'.

Par contre, j'aimerai avoir d'autres solutions.
Est ce que un fichier du type .htaccess contenant un allow_url_fopen à OFF peut faire l'affaire pour empecher l'ouverture de tout ce qui n'est pas en .php ?
Je ne peux pas le tester car je connais pas la procédure.

Dernière modification par Tyim (Le 30/05/2007, à 13:17)

inazo · Le 30/05/2007, à 13:53

Je vais répondre en plusieurs fois,

Pour comment fais-tu pour trouver les fichier .php~ ou .inc ?

Très facilement avec un aspirateur de site ou une attaque au dictionnaire des url possible rapide efficace. Logiciel IntelliTamper vieux mais utile sur pas mal de site.

Ensuite oui le fichier en .php4 ou .php est exécuté par le serveur mais le fichier .php~ ou .inc, sans changement de configuration du serveur, s'affiche en plaintext donc on voit tous le code non interprété avec mot de passe de base de données etc...

J'ai déjà trouvé cette faille deux fois et je peux vous dire que lorsque que l'on dit au webmaster cinq minutes après avoir commencer tiens ton mot de passe oracle c'est celui là il devient tout blanc.

On ne cherche donc pas à inclure les fichiers ni à savoir lequel est inclut et pourquoi on recherche tout simplement des indélicatesse du Web développeur pour voler des informations importantes.

Maintenant comment sécuriser cela ?

Simplement on interdit via un .htaccess la lecture de tous fichier se terminant par .inc et .php* sauf bien sur la page d'index ou les pages qui ne seront pas incluses pour des raisons x ou z.

Donc en gros on fait comme ceci :

<Files *.php*>
Order deny,allow
Deny from all 
</Files>

<Files *.inc*>
Order deny,allow
Deny from all 
</Files>

<Files index.php>
Order deny,allow
Allow from localhost
Deny from all 
</Files>

<Files contact.php>
Order deny,allow
Allow from localhost
Deny from all 
</Files>

Comme ceci vous devrez être un peu plus rassuré. Ensuite la faille du plaintext, comme je l'appel, est du à une mauvaise configuration des serveurs et des droit d'accès aux fichiers.

Je reste à disposition pour débat ou autre sur la sécurité.

Cordialement Inazo.

Psykotik · Le 30/05/2007, à 18:35

inazo a écrit :

Pour comment fais-tu pour trouver les fichier .php~ ou .inc ?
Très facilement avec un aspirateur de site ou une attaque au dictionnaire des url possible rapide efficace. Logiciel IntelliTamper vieux mais utile sur pas mal de site.

Je comprends pas comment un aspirateur de site peut faire mieux qu'un humain; il ne fait que suivre des liens indiqués sur la page, avec peut-être l'avantage de suivre des liens qui sont invisibles, désactivés.

Par contre, je comprends mieux avec une attaque brute; mais ça me paraît tellement aléatoire, ce genre de trucs, ça marche vraiment ? Je ne compte pas le nombre de fois où, dans mon passé windowsien, j'essayais des attaques brut force sur des fichiers zips protégés. Jamais réussi à trouver quoi que ce soit

inazo a écrit :

Ensuite oui le fichier en .php4 ou .php est exécuté par le serveur mais le fichier .php~ ou .inc, sans changement de configuration du serveur, s'affiche en plaintext donc on voit tous le code non interprété avec mot de passe de base de données etc...
J'ai déjà trouvé cette faille deux fois et je peux vous dire que lorsque que l'on dit au webmaster cinq minutes après avoir commencer tiens ton mot de passe oracle c'est celui là il devient tout blanc.
On ne cherche donc pas à inclure les fichiers ni à savoir lequel est inclut et pourquoi on recherche tout simplement des indélicatesse du Web développeur pour voler des informations importantes.

Le .php~ je peux comprendre qu'on le trouve "par hasard" (ahem). Mais le .inc ? Il est obligatoirement fait à la main, peut aussi bien être libellule.php.inc que hemoroides.php.inc .

Cela dit, je comprends que le webmaster aie quelque paniqué. J'en aurais fais de même

inazo · Le 30/05/2007, à 18:54

En fait cette aspirateur de site est très bien car il liste bien généralement sauf parfois ou il plante... Les fichiers php et .inc, .php~, .php4 etc...

Donc avec ce petit logiciel tout vieux on fait des merveilles. Après le brute force faut une machine juste pour cela ou essayer le logiciel Webscarab qui bien utilisé fait des miracles aussi ^^.

Cordialement Inazo.

Tyim · Le 30/05/2007, à 19:14

OK.

Bon. Pour maintenant autant renommer mes fichiers en fichier.inc.php ( c'est la meilleur méthode pour les fichiers à inclure ?)

Ensuite je vais mettre le fichier .htaccess comme tu nous as présenté.

Il doit être à la racine et ça suffit ? pas besoin d'être dans chaque dossier ?
Est ce que le .htaccess me préserve de mettre du code pour que le fichier ne s'ouvre pas en dehors de son contenant ?

Merci pour vos réponses

Tyim · Le 30/05/2007, à 19:40

Si je peux 'inazo', j'ai une autre question :

Il y a un contenant index.php qui contient le formulaire de connexion à la parti admin.
Ensuite les contenus sont inclus (include).

Si je ne fais rien, le visiteur peut se connecter directement au fichier.inc.php sans même avoir le besoin de se connecter.

Qu'est ce que tu me conseilles de faire pour sécriser cette partie ?
Est ce que le .htaccess résoud ce problème seul ?
Est ce que je dois jouer avec une variable SESSION pour vérifier que l'utilisateur est bien connecté ?
Ou as tu d'autres solutions ?

Merci. J'avoue que je me pose pas mal de questions pour sécuriser cette partie.

@redit :j'ai mis le fichier .htacces, et je n'ai plus accés à rien :
Forbidden
You don't have permission to access / on this server.
@rereedit: c'est le dernier ordre pour index.php qui ne fonctionne pas. C'est sans doute le localhost, mais je ne sais pas ce que je dois mettre à la place.

Dernière modification par Tyim (Le 30/05/2007, à 20:14)

inazo · Le 30/05/2007, à 22:13

Oui bien sur que tu peux ^^.

Bon pour le .htaccess oui il va protéger tout tes sous dossier à partir de son emplacement donc si tu le met à la racine il protègera tous les répertoires et sous répertoire de ton site. Et même les fichiers se trouvant à la racine directement.

A la place de localhot tu peux mettre le nom de domaine de ton site ou son adresse ip. Il est vrai que localhost ne fonctionne pas toujours sinon il te faut le nom du serveur sur lequel tu es pour remplacer localhost.

Pour les connexions c'est compliqué. Tu peux inclure ton script pour la vérification de la connexion en admin ce n'est pas un soucis. Si tu fais des vérification forte tu n'auras pas de soucis, ensuite pour conserver le fait que c'est bien un admin de connecté et non pas un utilisateur lambda ou un visiteur tu devras utiliser les SESSION.

Cependant je te met en garde qu'une SESSION mal utilisé est vraiment faible de plus tu devras fixer une durée de vie pour cette session sans activité je te conseil 5 minutes ce qui est largement sufisant. De plus je te renvoie à la documentation PHP sur les SESSIONS pour en apprendre un peu plus et te conseil ceci :

session_start();
session_regenerate_id(TRUE); // Ceci va changer l'identifiant de session et détruire les anciens fichiers de session.

Mais je penses que la prmière chose qu'il faut toujours garder à l'esprit :

Jamais faire confiance à toutes données transmise par un utilisateur, que se soit via un formulaire son navigateur son système, ces sessions ou ces cookies.

Je reste à disposition pour d'autre question.

EDIT :

Pour le .htacces :

<Files index.php>
Order deny,allow
Allow from localhost
</Files>

Désolé le premier code .htacces été mon code d'essai car je ne suis pas satisfait de celui là mais c'est aussi logique dans un sens de procéder de cette manière de toute façon vous pouvez autoriser votre index.php à être utiliser n'importe ou car de toute façon il s'exécutera toujour sur votre serveur et ceci est toujours vrai, on ne peut pas inclure de façon distante vos fichier en .php les autres commes de .inc on le pourrait si on ne faisait pas cette manipulation.

Cordilament Inazo.

Dernière modification par inazo (Le 30/05/2007, à 22:26)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 29/05/2007, à 23:01

PHP - Sécurité - inclusion et fichier .inc

#2 Le 30/05/2007, à 06:55

Re : PHP - Sécurité - inclusion et fichier .inc

#3 Le 30/05/2007, à 09:10

Re : PHP - Sécurité - inclusion et fichier .inc

#4 Le 30/05/2007, à 09:37

Re : PHP - Sécurité - inclusion et fichier .inc

#5 Le 30/05/2007, à 09:53

Re : PHP - Sécurité - inclusion et fichier .inc

#6 Le 30/05/2007, à 11:39

Re : PHP - Sécurité - inclusion et fichier .inc

#7 Le 30/05/2007, à 12:09

Re : PHP - Sécurité - inclusion et fichier .inc

#8 Le 30/05/2007, à 13:14

Re : PHP - Sécurité - inclusion et fichier .inc

#9 Le 30/05/2007, à 13:53

Re : PHP - Sécurité - inclusion et fichier .inc

#10 Le 30/05/2007, à 18:35

Re : PHP - Sécurité - inclusion et fichier .inc

#11 Le 30/05/2007, à 18:54

Re : PHP - Sécurité - inclusion et fichier .inc

#12 Le 30/05/2007, à 19:14

Re : PHP - Sécurité - inclusion et fichier .inc

#13 Le 30/05/2007, à 19:40

Re : PHP - Sécurité - inclusion et fichier .inc

#14 Le 30/05/2007, à 22:13

Re : PHP - Sécurité - inclusion et fichier .inc

Pied de page des forums