Page sécurisée en PHP ?

illicoo a dit:
Mon problème est que ce répertoire est hébergé chez Free, et ils ne permettent pas de "chiffrer" les mots de passe

voir plus haut....
Sinon un autre hébergeur.... mais gratuit?


illicoo
je comprend pas trop l'interet de chiffrer tes mots de passe... t'es de la CIA ? tu les stock comment et ou tes mots de passes...

si tu veux cacher un repertoire tu lui donne un nom a la con et tu recuperes les elements dedant en php coté serveur comme ça rien ne sort coté client et c'est bon... .htacces pas bon pour ce que tu as... ;)
 
Si je veux mettre en place un répertoire protégé,
c'est que j'ai mes raisons...
la n'est pas le problème

Visiblement il ne trouve pas mes mots de passe ?
J'ai utilisé cette methode pour touver le fichier mot de passe

Mais comment je trouve ce chemin absolu moi ?

En effet, c'est la plupart du temps délicat à trouver. Heureusement, il existe une fonction PHP qui va beaucoup nous aider : realpath.
Cette fonction donne le chemin absolu vers le fichier que vous indiquez. Vous allez donc faire comme ceci pour trouver le chemin absolu :

Créez un fichier appelé "chemin.php".
Mettez juste cette ligne de code dedans :
<? echo realpath('chemin.php'); ?>
Envoyez ce fichier sur votre serveur avec votre logiciel FTP. Placez-le dans le dossier que vous voulez protéger.
Ouvrez votre navigateur et allez voir ce fichier PHP. Il vous donne le chemin absolu, par exemple dans mon cas :
/home/sdz/www/gestion/admin/chemin.php
Copiez ce chemin dans votre .htaccess, et remplacez le "chemin.php" par ".htpasswd", ce qui nous donne au final par exemple :
/home/sdz/www/gestion/admin/.htpasswd
Supprimez le fichier "chemin.php" de votre serveur, il ne nous sert plus à rien maintenant qu'il nous a donné le chemin absolu
La ligne AuthUserFile indique donc où se trouve le fichier .htpasswd qui contient les mots de passe.

Enregistrez le fichier avec le nom "htaccess.txt" pour le moment, on le renommera en ".htaccess" plus tard.
Voilà, on a fini de créer le .htaccess, on peut maintenant passer au .htpasswd


Il me demande bien un mot de passe mais il refuse d'y aller?

ilicoo
 
illicoo a dit:
Mais comment je trouve ce chemin absolu moi ?

En effet, c'est la plupart du temps délicat à trouver. Heureusement, il existe une fonction PHP qui va beaucoup nous aider : realpath.
Cette fonction donne le chemin absolu vers le fichier que vous indiquez. Vous allez donc faire comme ceci pour trouver le chemin absolu :

Ce n'est pas la méthode à employer chez free qui a modifié php.

Dans ton fichier .htaccess, tu donnes le chemin jusqu'au fichier des mots de passe avec cette fonction:

PerlSetVar AuthFile secret/passlist.txt

Et tu dois avoir à la racine du site un dossier nommé secret qui contienne le fichier passlist.txt, (tu sécuriseras ce dossier ensuite, quand ça marchera). Tu peux le mettre ailleurs. Le tout est de donner le chemin depuis la racine du site.

Ton fichier .htaccess est dans le dossier à sécuriser. Le dossier à sécuriser est où tu veux. Le chemin donné dans .htaccess n'est pas relatif au dossier sécurisé mais à la racine du site.
Bon courage.:)
 
Vladrow a dit:
Elle est au plus simple. Et c'est la meilleure que tu puisses avoir simplement avec free.
Effectivement si tu ne quittes pas le navigateur, tu restes connecté au site.
Tout dépends du niveau de sécurité que tu désires et des conditions d'utilisations de ton ordinateur.
La quasi totalité des internautes ne pourra pas accéder au site sans le mot de passe.
Un hyper crack passera toujours.
Evidemment si tu ne ferme jamais ton navigateur et si tu ne souhaites pas qu'un utilisateur de ton ordinateur puisse accéder au site, on quitte les méthodes simples et tu dois trouver une méthode de "dés-identification", comme les sites sécurisés des banques. Là, je passe. :siffle:
Mais il me semble aussi simple de quitter le navigateur ;).

Et puis si c'est vraiment important, tu dois penser au cryptage des données des pages pendant le transfert, etc. etc. etc. A toi de régler ton besoin de sécurité par rapport à la simplicté et au coût.


Bonjour

Merci.
Mais je ne comprends pas, alors, en quoi une protection par .htaccess est plus sure qu'une protection par un script php ?

Albert
 
Si tu utilises PHP, tu utilises des formulaires, des requetes SQL ou vers un fichier, etc ... bref, il y a des dizaines de façon de contourner une protection PHP si le code ne tient pas compte de certaines mesures de sécurité. Cela demande pas mal de temps pour avoir un truc qui tienne vraiment la route, et pas mal de recherches si on débute.

Avec un .htaccess, tout se passe directement au niveau du serveur Web, et a moins de s'y attaquer avec un brute force, ou trouver une faille directement dans Apache ... je ne vois pas comment passer outre ;) De plus, c'est franchement simple a mettre en place.
 
[MGZ]Slug a dit:
Si tu utilises PHP, tu utilises des formulaires, des requetes SQL ou vers un fichier, etc ... bref, il y a des dizaines de façon de contourner une protection PHP si le code ne tient pas compte de certaines mesures de sécurité. Cela demande pas mal de temps pour avoir un truc qui tienne vraiment la route, et pas mal de recherches si on débute.

Avec un .htaccess, tout se passe directement au niveau du serveur Web, et a moins de s'y attaquer avec un brute force, ou trouver une faille directement dans Apache ... je ne vois pas comment passer outre ;) De plus, c'est franchement simple a mettre en place.

Merci
 
un peu plus de detaille parce que je ne comprend pas comment on peut contourner ce genre de protection ou tout ce fait coté serveur...

et je ne vois pas non plus le commun des mortels en etre capable, et je ne vois pas qui aurait un interets a hacker mon tit site tout php...
 
Il y a généralement moyen de modifier le comportement des scripts php en mettant certains infos dans les champs d'un formulaire.

On prend le cas le plus basique de chez basique. Le formulaire d'identification avec stockage des infos dans une base MySQL ! Un champ login, un champ password.

Généralement quand tu débutes avec ce genre de trucs tu recupères les données de tes champs via $_POST['login'] et $_POST['password'], et tu colles tout ça dans une requete MySQL mal fichue (pas de quotes, etc...).

"SELECT * FROM users WHERE login=".$_POST['login']." AND password=".$_POST['password']

Et tu testes si ça renvois quelque chose pour donner ou non acces a la page. La requete est peut-etre mal fichue, mais dans l'ensemble, ça ne parait pas poser de problème particulier de sécurité. Et pourtant si ... imagines que tu ais mis dans le champs password :

1 AND 1=1

La requete devient

SELECT * FROM users WHERE login=xxx AND password=1 AND 1=1

En gros, tu as une requete qui dis : selectionnes tout ou c'est vrai. Bref, il selectionne tout et le gars rentre dans la page sans meme s'etre cassé la tete.

Cas encore plus vicieux ... dans le champs login tu mets :

1; DROP TABLE `users`; COMMIT; --

La requete devient

SELECT * FROM users WHERE login=1; DROP TABLE `users`; COMMIT; -- AND password=1 AND 1=1

Une requete qui se transforme en trois requete, et ta table users qui disparait ! Et même pas de message d'erreur car la partie apres le -- est commenté.

Pour palier à ce genre de probleme il faut bien construire ses requetes pour emmerder le vilain mechant potentiel :

SELECT * FROM `users` WHERE `login` = 'xxx' AND `password` = 'yyyyy'

Secondo il faut vérifier le login, et le password entré dans le champ avant de les passer dans la requete. Pour les vérifications il faut tout d'abord virer tous les caractères ', ou tout du moins les transformet en \'. Pourquoi ? Pour obliger le vilain à mettre ses donnees vicieuses entre apostrophes :

1' AND 1=1

Si tu transforme le ' en \' la requete sql devient

SELECT * FROM `users` WHERE `login` = 'xxx' AND `password` = '1\' AND 1=1

Ce qui n'est pas une requete valide car il n'y a pas d'apostrophe de fin. bref MySQL ne va rien faire.

Ensuite il faut se prévenir des --, et autres ; ... bref il faut tripatouiller les infos pour etre sur que c'est de la forme demandée.

A chaque fois que l'on demande des infos venant de l'utilisateur, il faut absolument penser à un systeme qui ne soit pas détournable, et tester toutes les infos. C'est faisable, mais ça demande de farfouiller sur le net, et de faire des tests ... beaucoup de tests :D
 
mxmac a dit:
et je ne vois pas non plus le commun des mortels en etre capable, et je ne vois pas qui aurait un interets a hacker mon tit site tout php...

Si tu limites l'acces a une partie de ton site, c'est que tu ne veux pas que tout le monde s'y ballade... si tu ne veux pas que tout le monde s'y ballade, tu fais un peu attention a la conception du site, et à sa sécurisation. De plus, c'est un excellent moyen d'apprendre pas mal de subtilités. Surtout que c'est un travail absolument sans fin.

Iintégrer les mesures standard, c'est pas mal... et ça evite de prendre de mauvaises habitudes.

Si tu n'as pas envie de te faire suer => htaccess ... :D
 
Ah un dernier conseil ... n'essayez pas de jouer au p'tits zhackers en herbe sur de gros sites avec le procédé que je détaille un peu ci-dessus (injection sql) ... généralement ce genre de site possède de quoi s'en protéger, mais surtout de quoi logguer ce type d'attaques :p Toutefois je vous conseille de vous renseigner sur cette technique, et sur les autres, de façon a être en mesure de vous en protéger.

@+

Guillaume
 
ce genre de procedé marche quand tu donne des noms super attendus a tes tables si tu personnalise comment ils fond, ils ont pas de boules de crystals les vilains ?
 
[MGZ]Slug a dit:
Il y a généralement moyen de modifier le comportement des scripts php en mettant certains infos dans les champs d'un formulaire.

On prend le cas le plus basique de chez basique. Le formulaire d'identification avec stockage des infos dans une base MySQL ! Un champ login, un champ password.

Généralement quand tu débutes avec ce genre de trucs tu recupères les données de tes champs via $_POST['login'] et $_POST['password'], et tu colles tout ça dans une requete MySQL mal fichue (pas de quotes, etc...).

"SELECT * FROM users WHERE login=".$_POST['login']." AND password=".$_POST['password']

Et tu testes si ça renvois quelque chose pour donner ou non acces a la page. La requete est peut-etre mal fichue, mais dans l'ensemble, ça ne parait pas poser de problème particulier de sécurité. Et pourtant si ... imagines que tu ais mis dans le champs password :

1 AND 1=1

La requete devient

SELECT * FROM users WHERE login=xxx AND password=1 AND 1=1

En gros, tu as une requete qui dis : selectionnes tout ou c'est vrai. Bref, il selectionne tout et le gars rentre dans la page sans meme s'etre cassé la tete.

Cas encore plus vicieux ... dans le champs login tu mets :

1; DROP TABLE `users`; COMMIT; --

La requete devient

SELECT * FROM users WHERE login=1; DROP TABLE `users`; COMMIT; -- AND password=1 AND 1=1

Une requete qui se transforme en trois requete, et ta table users qui disparait ! Et même pas de message d'erreur car la partie apres le -- est commenté.

Pour palier à ce genre de probleme il faut bien construire ses requetes pour emmerder le vilain mechant potentiel :

SELECT * FROM `users` WHERE `login` = 'xxx' AND `password` = 'yyyyy'

Secondo il faut vérifier le login, et le password entré dans le champ avant de les passer dans la requete. Pour les vérifications il faut tout d'abord virer tous les caractères ', ou tout du moins les transformet en \'. Pourquoi ? Pour obliger le vilain à mettre ses donnees vicieuses entre apostrophes :

1' AND 1=1

Si tu transforme le ' en \' la requete sql devient

SELECT * FROM `users` WHERE `login` = 'xxx' AND `password` = '1\' AND 1=1

Ce qui n'est pas une requete valide car il n'y a pas d'apostrophe de fin. bref MySQL ne va rien faire.

Ensuite il faut se prévenir des --, et autres ; ... bref il faut tripatouiller les infos pour etre sur que c'est de la forme demandée.

A chaque fois que l'on demande des infos venant de l'utilisateur, il faut absolument penser à un systeme qui ne soit pas détournable, et tester toutes les infos. C'est faisable, mais ça demande de farfouiller sur le net, et de faire des tests ... beaucoup de tests :D


Tout ceci est passionnant et clair, merci.
 
Je suis de retour...

J'en suis toujours au même point !
Je n'ai toujours pas pu protégé mon repertoire

cela vient du mac?

J'ai essayé plusieurs logitiels de texte: beeedit, smultron, subEthaEdit et textedit
j'ai aussi testé sur plusieurs de mes sites et domaine
pour le ftp j'ai essayé fetch et cyberduck

avec cyberduck je me suis mis en mode de transfert ASCII et terminaison de ligne Mac ?
et j'ai modifié les fichiers htaccess.txt et htpasswd.txt une fois mis en ligne evec le point devant et en enlevant le .txt

je pense avoir fait le tour de toutes les solutions possibles, c'est a en devenir fou !!!

et je pense que cela vient du mac ?
est-ce quelqu'un peut me dire ou cela coince?

Bonne soirée a tous
illicoo
 
mxmac a dit:
ce genre de procedé marche quand tu donne des noms super attendus a tes tables si tu personnalise comment ils fond, ils ont pas de boules de crystals les vilains ?

Franchement ... pour peu que le gars est oublié de desactiver l'affichage des erreurs SQL (ce qui est plutot frequent)... tu trouves facilement comment sont nommés les tables. De plus les tables de bases ça tourne toujours plus ou moins sur le meme truc users, monsite_users, utilisateurs, admin, etc... pas besoin de boule de crytal ;) De plus le nom des tables n'est pas forcement utile. Tout depend de la requete.

Bon, et puis c'est vraiment un cas de base l'injection SQL ... je vais pas faire un court sur "comment rentrer dans un site web alors qu'on a pas les clés !". Tu me demandais un exemple, j'en ai fourni un. Et je t'assures qu'il y a un paquet de site perso qui ne sont pas du tout protegé contre ce genre de petite bidouilles qui sont a la porté du premier venu.
 
pas un cour sur comment hacker mais un cours sur comment proteger de base j'aurais rien contre... pour eviter les message d'erreurs c'est les @ au debut de la requette ???
 
Bonjour

J'ai enfin réussit...
Et j'ai trouvé mon erreur:
au moment de renommer les fichiers .htaccess et .htpasswd je faisait info sur les fichiers htaccess.txt et .htpasswd et je modifiais le nom et la il faut faire "enter" et non quitter la fenêtre info en cliquant en haut a gauche....
comme quoi cela ne tient pas a grand chose

merci a tous pour votre aide !
bonne fin de journée
illicoo
 
mxmac a dit:
pas un cour sur comment hacker mais un cours sur comment proteger de base j'aurais rien contre... pour eviter les message d'erreurs c'est les @ au debut de la requette ???

Soit tu mets un @, soit tu bidouilles le php.ini. Bref, le @ c'est bien. Et il faut aussi éviter d'afficher les mysql_error() a moins que l'utilisateur soit un admin par exemple, ou que le site soit en mode "debug".

Je vais essayer de regrouper de la doc en français sur les bonnes habitudes a prendre pour sécuriser un petit peu les sites php ;)

@+

Guillaume
 
[MGZ]Slug a dit:
Soit tu mets un @, soit tu bidouilles le php.ini. Bref, le @ c'est bien. Et il faut aussi éviter d'afficher les mysql_error() a moins que l'utilisateur soit un admin par exemple, ou que le site soit en mode "debug".

Je vais essayer de regrouper de la doc en français sur les bonnes habitudes a prendre pour sécuriser un petit peu les sites php ;)

@+

Guillaume

Ca nous serait utile, merci d'avance
Albert