J'ai fait un petit test ce matin, armé de Google (ptdr !) et en 15 minutes j'ai trouvé quand même 2 sites persos, 1 site Wa**z, et le site d'un éditeur de livre connu (faisant de la vente online même) vunérable à une simple recherche via google par non protection d'un fichier .inc ... autant dire une erreur de débutant.

ce forum a aussi des .inc, mais ce sont des fichiers de configs, donc aucun problème...
 
Faut voir le contenu des fichiers que tu as trouvé

Tous les users name, mot de passe, nom de db
Rien que ça

ha la évidemment respect !!  

ethernal a écrit a écrit : ha la évidemment respect !!

Mais le top ça reste le webmaster de l'Editeur de livres qui laisse tous ses scripts commentés dans des fichiers .inc
J'hésite à lui écrire mais après ce qui est arrivé à Kitetoa je préfère les laisser dans leur merde  

Je viens de trouver un winner all catégories : Une entreprise de sécurité informatique !!!
PTDR  

Il i a qq temps, on en avait parlé
ct le site de Le monde ou, un autre journal fr, où ou voyait les pass des db

C qd même dingues que des "professionnels" soient pas foutus de bien configurer leur serveur ou à défaut leur site !  

Scusé mon ignorence mais comment fait-on pour éviter ça ?
 
Perso mes fichiers sont tous .inc.php mais il y a autre chose à faire (comme htaccess ?)

Un fichier inc.php, si le serveur est bien configuré, s'exécutera et donc son contenu ne sera pas visible par l'internaute. Donc apriori pas de pb.
D'un autre coté un htaccess ne peut pas faire de mal  

Moi mes fichiers à inclure je fais inc_fichier.php . Po emmerdé comme ça ! Je vois pas l'intérêt de mettre .inc !!!!!!!!!!!!

 
Ben, parce que une règle.
Les fichiers à inclure doivent être nommés .inc.php et les classes .class.php

Effectivement mettre une extension .inc safépu et pour cause

 
C'est une regle    
 
Sa sert a rien !!

bozocarzu a écrit a écrit :     C'est une regle       Sa sert a rien !!

 
cékom réspékté le francé alaur ?

bozocarzu a écrit a écrit :     C'est une regle       Sa sert a rien !!

 
http://www.zephpmag.com/extraits/phpmag_02_sample.pdf
Ta tt les standart de codages

Ok, c'est peu etre plsu comprehensif, plus clair, mais si sa n'affecte pas le bon fonctionnement, je ne vois aucun interet a le mettre

c'est comme écrire sans fotes d'ortaugrafe, on comprend mais ça fait chier qd on veut relire

de plus, une bonne convention respectée, et en particulier la convention de nommage des variables et des fonctions, évite des bugs

Au lieu de renomer les *.inc en *.inc.php ou *.php, vous pouvez pas plutôt configurer apache un minimum ?
 
Il suffit de lui dire d'interpréter les *.inc comme des *.php
 
(suffit de chercher la ligne où on défini comment parche le PHP, la dupliquer, et remplacer *.php par *.inc )

on controle pas tt le temps le serveur.  

Je suis loin d'être un expert, mais dans le manuel de php, ils recommandent de configurer appache pour qu'il traite tout comme du php et ainsi pouvoir avoir des extensions html sur tous les fichiers...

De toute façon ce n'est pas normal qu'un professionnel fasse ce genre d'erreur.

dans le meme genre, certain editeur de texte font des sauvegarde automatique en .bak.... rechercher les  .php3.bak ou .php.bak sur google etait interessant

Google nous étonnera toujours

Le fait d'avoir "HTML" sur les fichiers, a mon avis, n'a pas grand intérêt. En effet, quand on envoie une querystring (?a=b&c=d) ou un queryform (méthode POST dans un formulaire) par exemple, on devine immédiatement que derrière il y a un serveur plus évolué. Et ensuite, PHP étant le plus répendu, on se pose même pas la question, c'est le premier truc qu'on va tester
 
Deplus, "html" dans les éditeurs avec mise en couleur de la syntaxe, ça va pas marcher comme ça d'entrée de jeu, il y a de grandes chances pour que l'éditeur ne reconnaisse pas le PHP, car se basant sur l'extension. Donc c'est pas forcément heureux comme choix
 
Mais sinon, il faut en effet tout indiquer comme étant à parser par le module PHP (ou autre langage sur les autres types de serveurs) ça évite ainsi d'avoir des trous énormes. Par contre, faut pas marquer les images pour l'interprétation hein Ca peut marcher, mais dans ce cas, le parseur va ramer tout ce qu'il faut pour analyser les images à chaque fois, donc c'est assez déconseillé

LOL, MDR
 
Marche bien aussi avec global.asa.bak
 

 
En plus ce boulay bn'a même pas mis de mot de pass à son utilisateur (et en plus ce saguouin utilise IUSR, le compte invité Web !!! pour se connecter à la base MDR)

tin c'est pas con j'y avais jamais pensé ! php.bak : 2450 reponses dans google

ce topic pourait etre plus interessant si vous expliquez vraiment ce qu il faut eviter pq la j ai pas tout compris, vous reprochez a ces gards de ne pas configurer leur serveur de facon a  interprété les fichiers .inc.php ? c bien ca?

nan *.inc tout court.
par défaut, PHP Apache renvoie ces fichiers sous forme de texte, mais le problème c'est qu'ils contiennent souvent des infos genre mot de pass d'accès à la base

 
a ok  
ensuite ds leur code il font  
include("./monFichierPass.inc" );
 
??
 
a oui c pas fut fut c sur

petite question (de débutant   ) :
quand vous parlez de fichiers .inc, se sont les fichiers au quel vous faitez appel avec la fonction include(MonFichier.inc.php); ou c'est autre chose ?

Ben oui, c'est des includes.
 
Mais il faut faire en sorte qu'Apache les exécute même s'ils ne sont pas inclus. Normalement, un include ne contient que des fonctions ou des déclarations de variables globales, mais n'affiche rien, donc si qq1 appelle ce fichier, il va rien voir, et la page ne contiendra rien, ce qui est mieu que le listing du code

Cybercouf a écrit a écrit : petite question (de débutant   ) : quand vous parlez de fichiers .inc, se sont les fichiers au quel vous faitez appel avec la fonction include(MonFichier.inc.php); ou c'est autre chose ?

c'est ca, sauf qu'ils ont oubliés le .php

ha ok merci
pour le moment je me suis servis qu'une seule fois de cette fonction mais avec un fichier MonFichier.php, donc je le changerais en MonFichier.inc.php