pages d'administration protégé par password

pages d'administration protégé par password - PHP - Programmation

Marsh Posté le 05-09-2003 à 10:04:14    

J'ai crée un ensemble de  page pour mon site pour me permettre d'uploader des choses ou de modifier mes bases sans passer par du ftp ou myadmin.
 
Tout marche bien. maintenant , avant d emettre ca en ligne, j'aimerais les protégée un peu ... je pensez faire une page admin.php aui me demande un pass/login et me renvoit sur admin_menu.php.
 
 
Est-ce la bonne méthode ? si oui comment coder le coup du password ?
si non que faire ?
 
Merci d'avance pour les reponses

Reply

Marsh Posté le 05-09-2003 à 10:04:14   

Reply

Marsh Posté le 05-09-2003 à 10:11:26    

Reply

Marsh Posté le 05-09-2003 à 10:13:17    

Joel F a écrit :

J'ai crée un ensemble de  page pour mon site pour me permettre d'uploader des choses ou de modifier mes bases sans passer par du ftp ou myadmin.
 
Tout marche bien. maintenant , avant d emettre ca en ligne, j'aimerais les protégée un peu ... je pensez faire une page admin.php aui me demande un pass/login et me renvoit sur admin_menu.php.
 
 
Est-ce la bonne méthode ? si oui comment coder le coup du password ?
si non que faire ?
 
Merci d'avance pour les reponses


 
Regarde du côté des sessions, parrait que c pas mal, pour ce que j'y connais.
 
Heu si non perso je vérifirai su chaque page que le type a bien rentré le mot de passe.


---------------
Le Tyran
Reply

Marsh Posté le 05-09-2003 à 10:15:24    


 
Tien je garde ça dans un coin, sa me servira peut être un jour  :whistle:


---------------
Le Tyran
Reply

Marsh Posté le 05-09-2003 à 10:17:15    

Reply

Marsh Posté le 05-09-2003 à 11:12:52    

Perso, je suis contre le htaccess pour une raison simple : On finit par ne plus rien chercher niveau sécu. Il vaut mieux apprendre et chercher par soi-même à sécuriser un site. Le htaccess devrait être utilisé pour COMPLETER le dispositif, et non CONSTITUER le dispositif à lui tout seul (enfin c'est juste mon avis).  :)

Reply

Marsh Posté le 05-09-2003 à 11:13:26    

tu preconiserais quoi ?

Reply

Marsh Posté le 05-09-2003 à 11:14:30    

Sur le même site, une variante avec un accès en PHP avec log+pass
http://www.phpdebutant.org/article47.php

Reply

Marsh Posté le 05-09-2003 à 11:15:55    

Joel F a écrit :

tu preconiserais quoi ?


 
Déjà une vérif de session sur TOUTES les pages d'administration.
Ensuite, si tu as différents trucs du genre index.php?cat=x, prévoir tous les cas de figure pour empêcher de remplacer x par n'importe quoi.
C'est déjà deux petites pistes, mais il y en a des tas. Sécuriser un site ne s'apprend pas en 2 jours...

Reply

Marsh Posté le 05-09-2003 à 11:18:46    

je me doutes merci de ces quelques pistes.

Reply

Marsh Posté le 05-09-2003 à 11:18:46   

Reply

Marsh Posté le 08-09-2003 à 13:14:32    

Joel F a écrit :

J'ai crée un ensemble de  page pour mon site pour me permettre d'uploader des choses ou de modifier mes bases sans passer par du ftp ou myadmin.
 
Tout marche bien. maintenant , avant d emettre ca en ligne, j'aimerais les protégée un peu ... je pensez faire une page admin.php aui me demande un pass/login et me renvoit sur admin_menu.php.


 
Dans ce cas là, il suffirait d'aller directement sur la page admin_menu.php pour avoir l'accès aux commandes sécurisées sans s'être authentifié :-/ Ou a moins de mettre un nom très complexe à trouver, et à condition bien sur qu'on ne puisse pas lister le répertoire ;)

Reply

Marsh Posté le 13-09-2003 à 01:50:54    

Que pensez vosu de ce systeme ce a l'air pas mal non ?
 
http://cserver.euroserv.com/admin/admin.htm
 
ps: commentil fait tout cela  :??:  
 
+

Reply

Marsh Posté le 13-09-2003 à 10:15:34    

il met un texte bien flippant, mais en fait y'a rien derrière :D
Nan j'sais pas :D

Reply

Marsh Posté le 13-09-2003 à 10:40:08    

Xwingz a écrit :

Que pensez vosu de ce systeme ce a l'air pas mal non ?
 
http://cserver.euroserv.com/admin/admin.htm
 
ps: commentil fait tout cela  :??:  
 
+
 


la connexion est en HTTP et pas en HTTPS donc pour l'aspect sécurité c'est bof

Reply

Marsh Posté le 13-09-2003 à 13:07:55    

Xwingz a écrit :

Que pensez vosu de ce systeme ce a l'air pas mal non ?
 
http://cserver.euroserv.com/admin/admin.htm
 
ps: commentil fait tout cela  :??:  
 
+
 

lol, j'oses pas imaginer la gueule du log d'erreur le jour où l'admin passes par un modem classique pendant qu'il télécharge.
En plus, pour peu que géographiquement parlant ils soient éloigné ou qu'il y ai un ggrois engorgement réseau, les trente secondes seront vite dépassé.
Quand a son idée de tout mettre dans des logs, c'est bien simple, par défaut tout accés a un serveur web de type apache est inscrit dans un fichier de log que ce soit un accés normal ou une tentative de piratage. ;)
Je vois pas vraiment ce qu'il y a de magique dans son système, en fait, ca me semble juste être un message à la con pour faire peur auxx apprentis pirates.

Reply

Marsh Posté le 13-09-2003 à 17:24:45    

Une soluce classique c:
- un formulaire de saisie
- une page php de vérif des l/p
- une variable de session qui permet dans chaque page de vérifier si l'utilisateur est bien enregistré
 
bon après tout ça c pour la forme étant donné que les l/p voyagent en non crypté sur le réseau ...
 
d'ailleurs je sais pas si vous avez remarqué mais par défaut sur la majorité des boites mail en ligne vos l/p ne sont pas cryptés...

Reply

Marsh Posté le 13-09-2003 à 17:40:25    

remittent a écrit :

d'ailleurs je sais pas si vous avez remarqué mais par défaut sur la majorité des boites mail en ligne vos l/p ne sont pas cryptés...

Ca dépend, serveur https, c'est toujours crypté.
Serveur http, ben là, c'est quarément rare que ca soit crypté.
 
D'où l'intérer d'utiliser des serveur https. ;)

Reply

Marsh Posté le 13-09-2003 à 18:49:21    

c bien ce que je dis, par défaut qd tu te connectes sur ta boite mail on the net c rare que ce soit crypté (ie : https)
 
d'ailleurs en http je vois pas commment tu pourrais avoir un cryptage!

Reply

Marsh Posté le 13-09-2003 à 18:57:08    

remittent a écrit :

c bien ce que je dis, par défaut qd tu te connectes sur ta boite mail on the net c rare que ce soit crypté (ie : https)
 
d'ailleurs en http je vois pas commment tu pourrais avoir un cryptage!

En utilisant du javascript par exemple. ;)

Reply

Marsh Posté le 13-09-2003 à 22:15:40    

ouais :) mais dans ce cas tu cryptes pas grand chose car tout le monde peut décrypter vu que tout le monde a accès au code source de la page...

Reply

Marsh Posté le 13-09-2003 à 22:59:57    

remittent a écrit :

ouais :) mais dans ce cas tu cryptes pas grand chose car tout le monde peut décrypter vu que tout le monde a accès au code source de la page...

J'ai dit que c'était crypté, pas que c'était impossible à craquer. ;)

Reply

Marsh Posté le 14-09-2003 à 01:16:59    

Hermes le Messager a écrit :

Perso, je suis contre le htaccess pour une raison simple : On finit par ne plus rien chercher niveau sécu. Il vaut mieux apprendre et chercher par soi-même à sécuriser un site. Le htaccess devrait être utilisé pour COMPLETER le dispositif, et non CONSTITUER le dispositif à lui tout seul (enfin c'est juste mon avis).  :)  


 
Il y a une seule bonne raison d'utiliser un htaccess. Pour sécuriser les fichiers d'include (mot de passe bdd)
 
Car si le démon apache tombe, le serveur se contentera de livrer les fichier php tel quel (la source donc!)
 
Avec les htaccess tu protège ton répertoire contre tout accès sauf 127.0.0.1
 
voilà quoi


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 14-09-2003 à 01:39:04    

JagStang a écrit :


 
Il y a une seule bonne raison d'utiliser un htaccess. Pour sécuriser les fichiers d'include (mot de passe bdd)
 
Car si le démon apache tombe, le serveur se contentera de livrer les fichier php tel quel (la source donc!)
 
Avec les htaccess tu protège ton répertoire contre tout accès sauf 127.0.0.1
 
voilà quoi

J'aurais plustôt pensé que si apache planté, ca renvérais plus rien du tout.

Reply

Marsh Posté le 14-09-2003 à 09:54:14    

omega2 a écrit :

J'aurais plustôt pensé que si apache planté, ca renvérais plus rien du tout.


 
+1, curieux cette histoire de serveur qui planté arrive encore à donner qqc...  :whistle:

Reply

Marsh Posté le 14-09-2003 à 11:46:02    

salut,
voici ma méthode (ou plutot celle que l'on m'a enseigné  ;) ):
 
<?php
if(!isset($PHP_AUTH_USER)) {
 Header("WWW-Authenticate: Basic realm=\"login - mot de passe\"" );
 Header("HTTP/1.0 401 Unauthorized" );
 echo "Texte à envoyer si le client appuie sur le bouton d'annulation\n";
 exit;
} else
{
 $user = "webmaster";
 $pw = "toto";
 
 if( ($PHP_AUTH_USER==$user) && ($PHP_AUTH_PW==$pw) )
 {
  echo "et voilà on est dans la partie admin!";
  echo "<br>ce code est protégé!";
 }
 else {
  Header("WWW-Authenticate: Basic realm=\"$PHP_AUTH_USER\"" );
  Header("HTTP/1.0 401 Unauthorized" );
  echo "Texte à envoyer si le client appuie sur le bouton d'annulation\n";
 }
 
}
?>
 
bon là on a le login et pass dans le code, mais vous m'avez compris hein, c'est un exemple  :whistle:


---------------
www.element62.com
Reply

Marsh Posté le 14-09-2003 à 16:08:43    

c clair que si apache est vraimant ko il va plus rien renvoyer du tout...
mais bon il y a plantage et plantage et la consigne de JagStang va dans le sens d'une amélioration la sécurité, on ne peut pas dire qu'avec un seul système de sécurisation on va tout couvrir donc qui peut le plus peut le moins.
 
Après, tout est une question de dosage, mais un bon début serait :
- variable d'authentification
- HTAccess
- pas de register global

Reply

Marsh Posté le 14-09-2003 à 16:32:00    

remittent a écrit :

c clair que si apache est vraimant ko il va plus rien renvoyer du tout...
mais bon il y a plantage et plantage et la consigne de JagStang va dans le sens d'une amélioration la sécurité, on ne peut pas dire qu'avec un seul système de sécurisation on va tout couvrir donc qui peut le plus peut le moins.
 
Après, tout est une question de dosage, mais un bon début serait :
- variable d'authentification
- HTAccess
- pas de register global
 


 
Ce n'est pas du tout suffisant. Ces protections (à part la variable d'auth.) corrigent les faiblesses d'apache et de php. hors, bien souvent, c'est le code moisi du programmeur qui constitue la première faille.
Des choses très simples comme une vérif d'une bête variable de session sur TOUTES les pages d'admin sont indispensables. Des interdictions automatiques d'IP quand le nombre de requêtes sur un script est trop élevé, aussi.
C'est pour cela que je n'aime pas tellement qu'on résume la sécurité d'un site à des .htaccess qui ne sont que des mesures complémentaires.

Reply

Marsh Posté le 14-09-2003 à 19:32:05    

Qd je parle de variable d'authentification c bien une variable qui sert de verif sur ttes les pages (cf post un peu plus haut)
 
Ensuite en matière de sécurité le niveau est déterminé par le maillon le plus faible ... souvent le code effectivement... et notamment au niveau des requetes SQL.
 
Mais bon y'a jamais de sécurité absolue et le tout est de bien mettre en accord les risques et les moyens à mettre en place (vlà l'intérêt de mettre du https sur un site perso)
 
Un petit topic qui fasse le topo de l'ensemble des astuces de sécurité que le tout à chacun peut facilement mettre en oeuvre sur son site (ça pourrait commencer par les register global, les caractères d'échappement en sql etc.) serait peut être utile?!

Reply

Marsh Posté le 14-09-2003 à 20:45:54    

Hermes le Messager a écrit :


 
+1, curieux cette histoire de serveur qui planté arrive encore à donner qqc...  :whistle:  


 
essaie de faire un tuer le démon. le PHP n'est plus interprété


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 14-09-2003 à 20:56:37    

JagStang a écrit :


 
essaie de faire un tuer le démon. le PHP n'est plus interprété

Heu, c'est quoi que t'apelles "le démon"?
Par ce que pour moi a partie du moment ou on tu un programme, il va plus réagir à rien vu qu'il est mort.
Alors, oui, c'est sur que les scripts php ne sont plus exécuté, mais a mon avi, c'est le cas surtout par ce que le serveur apache n'écoute plus rien vu qu'il a été tué.
 
Alors je te demandes de t'expliquer un peu mieux là. Moi, je parles du serveur apache en lui même mais toi, je me demandes bien de quoi tu veux parler, peut être d'un module optionnel d'apache, ou d'un programme serveur utilisé par apache, mais je penses pas que tu parle d'apache lui même.

Reply

Marsh Posté le 14-09-2003 à 22:33:07    

Un démon est un comme un service sous NT.  
http://www.linux-france.org/prj/jargonf/D/deacmon.html
 
C'est le démon qui interprète le PHP. Si le démon ne fonctionne plus, ça n'empêche pas le serveur de fonctionner
 


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 14-09-2003 à 22:52:44    

JagStang a écrit :

Un démon est un comme un service sous NT.  
http://www.linux-france.org/prj/jargonf/D/deacmon.html
 
C'est le démon qui interprète le PHP. Si le démon ne fonctionne plus, ça n'empêche pas le serveur de fonctionner
 
 

Ben justemebnt, sous windows, j'ai apache installé en service, et php fait partis intégrale d'apache, si je tu apache, j'ai plus aucun serveur http. Sous windows, je peux pas tuer php en laissant tourner apache.
 
Donc, en fait, c'est bien ce que je pensais, tu as php qui tourne séparément d'apache, c'est pas apache que tu tu mais le "service" php.

Reply

Marsh Posté le 14-09-2003 à 22:59:48    

oui il est clair que je parle pas d'Apache pour Windows... Les hébergeurs de PHP n'utilise PAS windows... (sauf s'ils veulent payer des licences pour rien.
 
Mais Apache sous windows c'est quasi du bidouillage...


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 14-09-2003 à 23:05:43    

Ps : Dans la page de ton lien :

Citation :

Un démon peut aussi être un sous-programme appelé par un programme principal (dans ce cas on parle « sérieusement » de DLL).


Heu, dire qu'une DLL est un démon, c'est vraiment un abus de language affreux.
D'ailleur, personellement, j'ai l'impression que dans cette définition là, il y a plus d'inexactitude qu'autre chôse.
Quand on la lit, ils disent :
un démon, c'est la même chôse qu'un driver sous d'autres OS. (faux)
Puis, un demaon, ca peut aussi être un sous programme (faux également)
 
Si tu prends une telle définition comme référence, c'est normal que la pluspart des informaticiens ne comprennent pas ce que tu raconte. ;)

Reply

Marsh Posté le 14-09-2003 à 23:09:37    

Bon.
 
Je suis informaticien. C'est pas un gars qui sait pas ce qu'est un démon qui va me faire la morale. Mais il est vrai que cette définition n'est pas terrible.
 


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 14-09-2003 à 23:12:11    

http://www.freebsd-fr.org/copyright/daemon.html


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 14-09-2003 à 23:38:23    

JagStang a écrit :

Bon.
 
Je suis informaticien. C'est pas un gars qui sait pas ce qu'est un démon qui va me faire la morale. Mais il est vrai que cette définition n'est pas terrible.
 
 

Ho là là, je sais pas ce qu'est un démon, j'ai plus qu'à me pendre alors. :p
 
Pour moi, Apache sous windows, c'est en aucune façon de la bidouille. Mais je n'irais pas jusqu'a dire que c'est une config idéale pour faire un site web commercial ou personnel, mais chez moi j'ai qu'une seule machine et aucune envie de m'embêter avec l'installation et la configuration d'un unix pour développer mon site.
D'aillieur, il me semble qu'apache est aussi stable sous windows que sous les autres OS, signe que c'est pas une telle bidouille que ça surtout vu la facilité d'installation. ;)
 
 
Bon, pour en revenir au début de notre discution, quand tu dis "tuez le démon apache et le php ne sera plus interprété", je paris que tu veux dire "tuez le processus php utilisé par apache ...". D'aillieur, dans ton premier message, tu disais "si "
 
Au fait, une dernière remarque et après, j'arrêtes. Pour le fichier .htaccess la raison que tu évoques n'est pas a mon avis "la seule bonne raison" d'en utiliser un.  
Certain l'utilises pour limité l'accés à un dossier à l'aide d'un mot de passe, d'autres bloquent l'accés aux fichiers portant telle ou telle extension soit pour tout le monde, soit pour tout le monde sauf certaines IP. Ce ne sont peut être pas a chaque fois d'exellente raisons mais il y a des cas où ca en est.
Chez moi, j'ai mis les .php5 avec accés limité au localhost le temps de tester tous mes scripts avec les nouvelles spécificités et le temps qu'une version officielle en dehors des versions beta sorte enfin. ;) (bon, moi, je l'ai pas fait dans un .htaccess mais directement dans le fichier de config d'apache vu que j'ai la main dessus)
Une autre raison pour les .htaccess : définir des fichiers d'erreur 403, 404 ou autres. ;) Si t'as pas un serveur dédié, c'est souvent le seul endroit où tu peux le régler.

Reply

Marsh Posté le 14-09-2003 à 23:42:13    

Reply

Marsh Posté le 15-09-2003 à 03:43:20    

donc sinon vous pensez quoi du script de secu de se site pour proteger la zone admin ?
 

Reply

Marsh Posté le 15-09-2003 à 14:15:12    

D'accord avec ce que tu as dit. Mais garde bien une chose à l'esprit... Apache = Linux
 
C'est comme les gars qui font tourner du PHP avec IIS. C'est possible, mais à quel prix !
 
Moi aussi je développe sous Windows avec EasyPHP, c'est dire. Mais c'est juste pour la phase de dév
 
Voilà quoi
 

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed