Bonjour
 
Pour ouvrir une connexion à une base de données, j'ai besoin, assez classiquement, de faire quelque chose genre connect (bdd,user,mdp).
Ce mot de passe est en clair à ce moment là dans mon code php.
J'ai placé cette séquence de connexion dans un fichier connexion.php, dans un répertoire "script"
Ma question, c'est comment m'assurer que quoiqu'il arrive, ce fichier ne puisse pas être récupéré ?
J'ai commencé par mettre un fichier index.html dans le répertorie script.
 
J'imagine qu'il y a mieux ?
Par exemple es-ce que je peux vérifier que ce fichier "connexion.php" n'est appelé que par une page php sur mon hébergement ?
Y ajouter un fichier .htaccess/.htpassword ? (mais esce que ca permettre à mes pages php d'y accéder quand même) ?
 
Merci de vos conseils, j'ai vraiment, mais vraiment pas envie que certains mdp puissent être récupérés    

Ben déjà, il ne peut pas être récupéré par un accès http puisqu'il sera interprété, donc l'utilisateur aura une page html affichant rien du tout.
 
Après, il peut être lu par l'admin du serveur web ou qq'un qui arrive à s'y introduire en piratant l'accès. Dans ce cas, ça n'a pas grande importance car dans les 2 cas, ils auront les droits pour changer les login/mdp des applis, de mysql et autres softs...
 
Du reste, regardes toutes les applis codés en php (mediawiki, Magento...) : le login/mdp est dans un fichier php ou xml. Après, y'a une lib dans le framework Zend ("guard" qq chose) qui permet de protéger certains fichiers, y'a eu un topic sur qq'un qui voulait protéger la clé de chiffrage/décryptage par ce moyen y'a pas longtemps

Merci de la réponse.
 
Pour mes deux questions, c'est possible ? Inutile ?
 
Même si c'est inutile, la première m'intéresse particulièrement.
 

Oui c'est possible et inutile tu peux créer un htaccess/htpasswd sur un repertoire 'include' par exemple.

Si quelqu'un essaye d'aller dans ton répertoire 'include' à partir de son navigateur on lui demandera de s'identifier. Par contre tes scripts PHP pourront y accéder.

Q1 : à ma connaissance non. Ou alors, définir une constante dans toutes les pages qui appellent connexion.php et vérifier dans ce script si la constante existe ou pas. Mais encore une fois, si connexion.php ne sert qu'à stocker les login/mdp pour se connecter à la BD, ça sert à rien de le protéger depuis un appel via une url puisqu'il sera interprété et que le résultat de son interprétation sera une page blanche dans le navigateur...
 
Q2 : .htpassword sert à faire une authentification d'utilisateur pour accéder à une partie d'un site web. Dans ton cas, ça ne te sera pas utile pour permettre à php de créer une connexion à la BD. .htaccess peut permettre d'éviter de parcourir un répertoire. Donc si tous tes fichiers à inclure se trouvent dans un même répertoire, ça peut aider, mais encore une fois, l'utilisateur verra le résultat du fichier interprété...
 
Mais si ça peut te rassurer, vue les questions que tu poses, je dirais que tu débutes en php. Du coup, les pbs de sécurité que tu soulèves sont bien moins graves que les failles de sécurité que tu vas probablement introduire toi-même dans ton code par méconnaissance de failles telles que le SQL injection, les failles XSS et autres joyeusetés qu'on trouve couramment dans des applis de type web.
 
Donc, utiliser la lib PDO + requêtes préparées (ou utilisation de mysql_real_escape_string()), strip_tags() et addslashes() sur tout ce qui vient d'un champ texte d'un form.
 
+les pbs dus aux charset (iso-8859-1 vs utf-8), ça, c'est sympa à résoudre aussi

 
 
Paradoxalement, du php crois moi j'en ai bouffé des kms, à base de formulaires principalement, et c'est pas d'hier...
 
Jusqu'à aujourd'hui, ca a toujours été pour des accès en bdd, dans un intranet.
Je limitais mes accès à la BDD pour le requettage que depuis 127.0.0.1, mettais mon fichier de connexion dans un répertoire non listable, et l'affaire était entendue.
La criticité de ces données de login/mdp n'était pas très importantes, limitées à un intranet pour des données pas franchement sensibles.
 
Aujourd'hui j'ai besoin de plus que d'un login à une bdd, sur un accès public, et me reposer des questions de sécurité est selon moi plus important que de me la jouer : "ca fait 10 ans que je fais comme ca, alors je sais faire".
C'est dingue de conclure hâtivement que quelqu'un y connait rien juste par ce qu'il pose une question anodine...
Je sais bien que le php est interprété, et que l'utilisateur "malveillant" ne tirera pas grand chose de l'appel de mon script en direct.
 
Mais après, tout connement, il suffit que je ne mette pas de fichier d'index à mon répertoire, et là hooo miracle, clicdroit, enregistrer sous, qu'il est beau le fichier avec tous les codes d'accès...
C'est pour éviter ce genre de piège con que j'interroge ici, voir ce que j'aurais pu oublier.
 
Edit : Pour ta remarque en Q1, j'ai mis une variable de session qui m'indique à priori si l'appel vient d'une page du site, et comme c'est une page qui est l'action d'un formulaire, je vérifie que j'ai des variable POST avant de lancer le script.
 

Oui, alors ca c'est le domaine où il faut que je me blinde.
addslashes(),je m'en sers depuis longtemps, le reste non  
 

M'en parle pas    
J'ai tous mis en utf-8, super, mais mon hébergeur aime pas ca du tout, il refuse mon "session_start()" si il est dans un fichier en utf-8 ! L'allu complete, j'ai cherché un temps fou d'où venait le problème...
Du coup, j'ai crée un fichier php en "ansi" juste pour démarrer ma session, puis j'ai inclu le reste du code qui est dans un fichier en utf-8.
 
Sans déconner pourrait pas y avoir un standard imposé...

Je ne voulais pas te froisser, cependant, à la lecture de ton message, je trouve effectivement paradoxal que tu aies "bouffé des kms de php" et que tu me sortes des phrase du genre :

 
Si, via un navigateur, tu peux parcourir un répertoire, quand tu vas faire clic droit "enregistrer sous" sur un fichier php, c'est, là encore, la version interprétée que tu vas récupérer (donc fichier vide)   Y'a donc pas de pb de sécurité, juste le fait que l'utilisateur pourra voir l'architecture de tes fichiers (un .htaccess peut donc être ne bonne chose, moins t'en montre mieux c'est).
 
Concernant les requêtes préparées et autres fonctions pour se "protéger", aujourd'hui, pour une appli moderne en php, c'est la base. Et pour protéger les entrées provenant de formulaires, des frameworks comme Znd ou Symfony disposent de fonctions toutes faites et sûres pour t'aider
 
Conclusion : t'as beau avoir fait beaucoup de php, manifestement tes connaissances ne sont plus à jour...

perso je fais comme toi, g des scripts de connexion dans un rep et dedans je mets un .htaccess contenant

et oui, tu peux y acceder depuis tes scripts, ce htaccess, c'est pour qu'apache refuse les requêtes de l’extérieur, pas des scripts php qui s'exécutent sur le serveur qui eux y ont accès.

de plus,il faut jamais stocker des mots de passe, utilise des sommes MD5.

de plus 2. au sujet des sessions, tu peux mettre en entete de tes fichers un truc du genre :

ça va rediriger tout appel à tes scripts pour des non identifiés.

+1 pour le md5 pour protéger les mdp des utilisateurs stockés en base. Mieux, du sha-1
Perso, je hashe même le login (en plus du mdp) et vérifie sur des sites qui ont des rainbow tables md5 que les login/mdp de mes utilisateurs sont suffisamment "forts". Si c'est aps le cas, je les préviens...

En effet, c'est bien pour ça que je viens créer un thread ici pour les réactualiser  

 
Alors là ca me troue le c*l    
Je pensais que dans un navigateur, le listage des fichiers était une sorte de mise à disposition de tous les fichiers du répertoire, que tu pouvais ainsi mettre à disposition des fichiers pour d'autres personnes.
Alors là je reste bouche bée.    

 
Ca,  c'est ce que je fais toujours quand c'est moi gère la bdd. Du md5, pas de stockage ou d'échange de mdp.
Mais dans le cas présent, je souhaite utiliser l'interface SOAPI d'ovh, avec des scripts fournis du genre :  

 
Et là, c'est bien sur pas moi qui gère...
 
 
 
 

 
Du sha-1 ? Mieux que du md5 ? Je vais me documenter
Tu hashe le login ? Tu peux m'expliquer l'intérêt ? Dans ta bdd tu gardes quand même le login en clair en plus du login hashe, n'es-ce pas ?
Enfin là c'est plus pour ma culture perso, en l'occurrence pour le cas qui me préoccupe, je ne gère pas d'accès en bdd que je possède.

 
T'as qu'à tester. Mais le fait que tu sois surpris montre que t'as pas bien capté le mécanisme derrière ce listage des fichiers d'un répertoire. Apache est un serveur web qui diffuse au navigateur web des pages (fichiers) demandées par un utilisateur. Pour certaines extensions, il appelle un binaire, c'est le cas des fichiers .php, apache appelle php.exe (parce que dans le fichier de conf d'apache, tu lui as dit de faire ça. Si tu lui précises pas, apache va envoyer le fichier .php comme si c'était un fichier txt, et là, oui, tu verras le code source du coup, sauf qu'aucune appli php ne pourra être exécutée sur ton serveur, donc tu vas rapidement te rendre compte qu'il y a un truc qui va pas Et contre ça, même un .thaccess ne peut rien si l'utilisateur connais l'url de ton fichier .php.
 
Donc si apache est configuré pour exécuter des fichier .php mais que l'utilisateur peut parcourir un répertoire sur ton serveur web, s'il clique sur un fichier .php (ou "enregistrer sous" ), apache va lui envoyer le fichier mais interprété puisque dans sa conf, on lui a dit que les .php devaient d'abord être interprétés par php.exe. Ca marche aussi pour les .asp (mais interprétés par un autre binaire)...
 
C'est plus clair?

 
Oui, sha-1 est mieux que md5 car le md5 a été "cracké" (une équipe de mathématiciens japonais il me semble) il y a qq années. Plus exactement, md5 n'étant pas bijectif et son espace résultant de la transformation étant fini par rapport à celui de départ (les chaînes à hascher), y'a une probabilité non nulle d'avoir des collisions, c'est-à-dire que 2 chaînes différentes donnent le même hash md5.
 
Sinon, oui, je hashe le login mais dans mes applis, le login est un champ différent du "pseudo" (ou nom/prénom), c'est-à-dire l'identité de l'utilisateur affichée dans l'IHM. Par ailleurs, comme j'avais pas accès à une époque à du https, je générais en Javascript le hash md5 du login/mdp et mettait ces 2 infos hashées dans un form cachée et c'était lui qui était envoyée au serveur, le formulaire de saisie du login/mdp par l'utilisateur n'étant pas envoyée. Du coup, si l'utilisateur avait désactivé JS, rien n'était envoyé en clair sur le serveur, et si JS est activé, y'a que les 2 hashs md5 qui sont envoyés au serveur. Comme ça, si les infos sont interceptées, y'a rien en clair.
 
Côté php, je vérifie bien que les infos reçus du form d'authentification sont bien 2 chaînes md5. Comme ça, pas de risque que qq'un qui aurait intercepté les hashs, les balances direct à l'appli et réussisse à se connecter
 
Maintenant, j'ai accès à du https, donc c'est plus vraiment utile. Et ma façon de faire à l'inconvénient de ne pas être accessible pour une personne handicapée visuellement qui utiliserait un navigateur sans JS (pas accessible A, AA, AAA)

Je l'ai fais direct avant de poster, tellement j'hallucinais en lisant ton post
Pour moi le listage apache, c'était comme un listage ftp, c'était "différent" d'un appel de page php qui lui faisait interpréter le code au serveur php.
 

En effet, ca j'en suis conscient depuis le départ : E[n]^inf -> E [n]^(je sais plus quelle taille, mettons 64) , ya forcement des collisions.
Mais je n'estimais pas ca comme une faille (s'en est une, mais de là à ce qu'elle serve concretement, j'estime (à tords peut-etre) que c'est négligeable).
Après, je peux regarder comment implémenter du sha-1, si c'est pas trop contreignant...
 
Merci pour les détails et explications    
 
Sinon, quelque chose de particulier à faire en plus pour protéger le mot de passe de mon compte ovh via l'interface SOAPI ? J'imagine que non.
 

php intègre déjà une fonction sha-1, donc facile avec php Pas la peine de mettre en place qq chose dont on sait déjà que ça a été cracké si on a une solution facile à mettre en oeuvre qui, elle, ne l'a pas été
 
Pour mieux protéger tes login/mdp, regarde ça : http://www.zend.com/fr/products/guard/
 
Après, tu peux toujours mettre les logins/mdp dans une BD et les crypter et trouver un moyen de "planquer" la clé de cryptage.
 
Regarde aussi si les infos sont envoyées en clair via la fonction $soap->login(). Si c'est le cas, pas la peine de crypter les login/mdp avec une telle faille de sécurité

Es-ce que je dis une connerie si je dis que je ne dois pas utiliser "addslashes" par ce que le phpinfo() de mon hébergement indique  '--enable-magic-quotes'  , que
"echo get_magic_quotes_gpc() ;" me donne 1 en résultat,

par ce que la doc php indique :
La directive PHP magic_quotes_gpc est à on par défaut, et elle appelle addslashes() sur toutes les données GET, POST et COOKIE. N'utilisez pas addslashes() sur des données déjà protégées avec magic_quotes_gpc sinon vous doublerez les protections. La fonction get_magic_quotes_gpc() est utile pour vérifier ce paramètre.

?