Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1798 connectés 

  FORUM HardWare.fr
  Programmation
  PHP

  [PHP]Protéger l'accès à un fichier php contenant des mots de passe

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[PHP]Protéger l'accès à un fichier php contenant des mots de passe

n°2074707
tuxbleu
renie ses origines
Posté le 09-05-2011 à 11:39:56  profilanswer
 

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  :sweat:  


---------------
Mon topic de vente - Mon feed-back
mood
Publicité
Posté le 09-05-2011 à 11:39:56  profilanswer
 

n°2074759
rufo
Pas me confondre avec Lycos!
Posté le 09-05-2011 à 13:57:10  profilanswer
 

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 ;)


Message édité par rufo le 09-05-2011 à 13:59:17

---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2074787
tuxbleu
renie ses origines
Posté le 09-05-2011 à 15:39:33  profilanswer
 

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.
 

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) ?


---------------
Mon topic de vente - Mon feed-back
n°2074829
egege
Posté le 09-05-2011 à 17:37:49  profilanswer
 

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.

 


Message édité par egege le 09-05-2011 à 17:38:14
n°2074833
rufo
Pas me confondre avec Lycos!
Posté le 09-05-2011 à 17:44:41  profilanswer
 

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 ;)

Message cité 1 fois
Message édité par rufo le 09-05-2011 à 17:46:34

---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2074947
tuxbleu
renie ses origines
Posté le 10-05-2011 à 12:16:35  profilanswer
 

rufo a écrit :

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.
 

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.


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

+les pbs dus aux charset (iso-8859-1 vs utf-8), ça, c'est sympa à résoudre aussi ;)


M'en parle pas  :cry:  
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é...

Message cité 1 fois
Message édité par tuxbleu le 10-05-2011 à 12:25:17

---------------
Mon topic de vente - Mon feed-back
n°2074955
rufo
Pas me confondre avec Lycos!
Posté le 10-05-2011 à 13:13:28  profilanswer
 

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 :

tuxbleu a écrit :


[...]
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.
 
[...]
 

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.


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


 
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)  :o 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...

Message cité 2 fois
Message édité par rufo le 10-05-2011 à 13:14:04

---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2074963
rengzehn
Posté le 10-05-2011 à 13:38:00  profilanswer
 

tuxbleu a écrit :

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.

 

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) ?


 

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

 
Code :
  1. deny from all
 

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 :

 
Code :
  1. if (!isset($_SESSION['login'])) {header('location: http://pbskids.org/teletubbies/teletubbyland.html'); exit();}
 

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

Message cité 1 fois
Message édité par rengzehn le 10-05-2011 à 14:09:19
n°2074967
rufo
Pas me confondre avec Lycos!
Posté le 10-05-2011 à 13:46:14  profilanswer
 

+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...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2074980
rengzehn
Posté le 10-05-2011 à 14:11:01  profilanswer
 

rufo a écrit :

+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...


 
 [:whiskas]

mood
Publicité
Posté le 10-05-2011 à 14:11:01  profilanswer
 

n°2074981
tuxbleu
renie ses origines
Posté le 10-05-2011 à 14:13:17  profilanswer
 

rufo a écrit :

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 :


 

rufo a écrit :


 
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)  :o 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...


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


---------------
Mon topic de vente - Mon feed-back
n°2074984
tuxbleu
renie ses origines
Posté le 10-05-2011 à 14:21:55  profilanswer
 

rufo a écrit :

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)


 
Alors là ca me troue le c*l  :ouch:  
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.  :sweat:  


---------------
Mon topic de vente - Mon feed-back
n°2074992
tuxbleu
renie ses origines
Posté le 10-05-2011 à 14:29:45  profilanswer
 

rengzehn a écrit :


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

Code :
  1. deny from all


 
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 :
 

Code :
  1. if (!isset($_SESSION['login'])) {header('location: http://pbskids.org/teletubbies/teletubbyland.html'); exit();}


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


 
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 :  

Code :
  1. <?php
  2. try {
  3. $soap = new SoapClient("https://www.ovh.com/soapi/soapi-re-1.21.wsdl" );
  4. //login
  5. $session = $soap->login("xxxxxx-ovh", "******","fr", false);
  6. echo "login successfull\n";
  7. //accountAlertThresholdSet
  8. $soap->accountAlertThresholdSet($session, "" );
  9. echo "accountAlertThresholdSet successfull\n";
  10. //logout
  11. $soap->logout($session);
  12. echo "logout successfull\n";
  13. } catch(SoapFault $fault) {
  14. echo $fault;
  15. }
  16. ?>


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

rufo a écrit :

+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 ....


 
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.

Message cité 1 fois
Message édité par tuxbleu le 10-05-2011 à 14:37:34

---------------
Mon topic de vente - Mon feed-back
n°2075011
rufo
Pas me confondre avec Lycos!
Posté le 10-05-2011 à 15:25:40  profilanswer
 

tuxbleu a écrit :


 
Alors là ca me troue le c*l  :ouch:  
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.  :sweat:  


 
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?


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2075013
rufo
Pas me confondre avec Lycos!
Posté le 10-05-2011 à 15:34:53  profilanswer
 

tuxbleu a écrit :


 
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.


 
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) :/


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2075252
tuxbleu
renie ses origines
Posté le 11-05-2011 à 12:48:35  profilanswer
 

rufo a écrit :


 
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?


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.
 :jap:


---------------
Mon topic de vente - Mon feed-back
n°2075253
tuxbleu
renie ses origines
Posté le 11-05-2011 à 12:57:17  profilanswer
 

rufo a écrit :


 
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) :/


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  :jap:  
 
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.
 

6.//login  
7.$session = $soap->login("xxxxxx-ovh", "******","fr", false);
8.echo "login successfull\n";


 
 :jap:


---------------
Mon topic de vente - Mon feed-back
n°2075268
rufo
Pas me confondre avec Lycos!
Posté le 11-05-2011 à 14:25:36  profilanswer
 

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é :/


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2078795
tuxbleu
renie ses origines
Posté le 27-05-2011 à 18:26:43  profilanswer
 

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.

 

?


Message édité par tuxbleu le 27-05-2011 à 18:27:03

---------------
Mon topic de vente - Mon feed-back

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  PHP

  [PHP]Protéger l'accès à un fichier php contenant des mots de passe

 

Sujets relatifs
forcer telechargement fichier jpg[AIDE] XSD, XSL, fichier config...
Recuperation d'informations Telnet avec PHPAide ! Récupérer le langage binaire d'un fichier.
Upload de fichiers en PHP : corruption des donnéesenvoi de gros fichier par socket
Accès à "CreateComponent" depuis un module ?Validation formulaire d'upload de fichier sans changer de page
[Php/Sql] Problème Order By 
Plus de sujets relatifs à : [PHP]Protéger l'accès à un fichier php contenant des mots de passe


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR