sécuriser l'accès à une partie d'un site PHP

[cvmh]

Bonjour

Pour certaines zones sensibles réservées à des membres enregistrées, je crée un formulaire demandant login et password. Ces données sont envoyées en POST au même fichier qui se connecte à la base pour vérifier que cet utilisateur dispose bien des droits d'accès. Si c'est le cas, je le redirige par exemple via un header('Location :...') après avoir enregistré son identifiant d'utilisateur en variable de session.

Les pages réservées aux membres sont toutes soumises à une condition qui vérifie que la variable de session correspondant à son id utilisateur existe bien. Si ce n'est pas le cas, celui est renvoyé sur la page d'identification toujours via un header.

Cette méthode a toujours fonctionné sans problème. Cependant, je vais avoir à mettre en place un site où les données sont véritablement sensibles et où mon client souhaite un système fiable à 200%.

Est-ce que mon système d'accès vous semble correct ? Avez-vous d'autres techniques à proposer ?

Merci pour vos conseils !

[stopher]

Salut ,

Malheureusement , rien n'est sure à 200% ...

Je suis loin d'être un expert en sécurité , mais déjà je pense qu'il peut être intéressant de travailler avec des données cryptés md5 par exemple .. et aussi pour l'espace sécurisé , travailler en ssl ...

Mais ce n'est que mon point de vue j'ai hâte de voir les réponses de personnes qui s'y connaissent plus en sécurité web ..

[destroyedlolo]

Ton systeme peut etre contourne sans trop de probleme.

Si tu veux vraiment un truc securise a 200% comme tu le dis, je te conseille tres fortement d'utiliser une authentification HTTP, sur du https, ce qui est la seule methode offrant vraiment un minimum de securite (c'est relativement simple de casser une session).

Regarde dans l'historique de mes post, qq'un avait deja pose ce genre de questions.

Les versions 2.2 d'apache permettent en theorie une authentification http sur une base de donnee ... sauf que c'est passablement bugger et je n'ai pas reussi a le faire fonctionner, du moins avec PostGRESQL. La solution que je preconise utilise uniquement PHP pour faire l'authentification mais il faut que le serveur soit configurer pour laisser passer le mot de passe.

[cybermad]

Salut,

Tu veux pouvoir sécuriser un accès ? Il y a encore quelques possibilités qui s'offre à toi. J'ai toujours dit que je ferais un tuto pour un accès membre "super sécurisé". J'avais fait un truc pour un site mais je me suis rendu compte de ses faiblesses.

Attention j'ai dit de ses faiblesses, pas de ses failles ;-)

J'avais un site avec un accès membre. Plus tard j'ai voulu ajouter un forum qui conservait la session de mon site internet de façon que, quand un membre se loguait ou sur mon site, ou sur mon forum, il soit logué pour les deux:

=> Malheureusement cela a été impossible. J'ai dû dire au revoir à mon système pour coupler les deux... alors il faut être sûr de ce que tu veux.

Cela dit je suis d'accord à 100% avec destroyedlolo qui dit qu'aucun système n'est infaillible.

Voilà ce que j'avais fait:

- un système login - mot de passe (rien d'extraordinaire pour l'instant ;-)

Mais le mot de passe doit être stocké en MD5 ou autre, ou multiplié par une constante connu de toi seul puis chiffré en MD5...

Au moment de la comparaison, tu effectues les bonnes opérations sur le mot de passe afin de faire la comparaison:

=> sécurité 1: le mot de passe n'est pas stocké en clair dans la bdd.

Le reste de la sécurité vient de la session:

- Tu crées une session avec "session_start();" C'est donc une session au niveau serveur.

=> sécurité 2: si tu fermes le navigateur, bye !

- Tu mets un cookies sur l'ordinateur connecté avec dedans, un identifiant aléatoire généré aléatoirement (40 caractères par ex.). Bien sûr à la connexion tu insères dans une table de ta base de donnée le lien entre cet identifiant et l'ID membre (ou le mot de passe crypté). A chaque mouvement dans l'espace membre, tu vérifie la présence du cookies.

=> sécurité 3: si la personne shoote les cookies pendant sa session: bye !

- Toujours dans la fameuse table du dessus, tu insères l'IP de la personne (récupéré par un $_SERVER["SERVER_ADDR"])

=> sécurité 4: si la personne change de proxi, bye !

Moi je m'étais arrêté au dessus mais tu peux continuer:

- tu peux égayer tout ça en faisant passer une variable de session dans l'url. Variable qui est biensûr différente de toute les autres, toujours stocké dans la fameuse table.

- tu peux pousser le vis jusqu'à changer ta variable de session à chaque chargement de page... à chaque fois mis à jour dans ta bdd.

- tu peux aussi ajouter un timer qui défini une durée de session si inactif pendant 5 minutes par ex.

Chaque exemple est complémentaire, c'est à dire que si une personne prend l'IP (imaginons une famille en réseaux; même IP). Mais il faut le cookies qui est généré à la connexion, s'il existe un cheval de troie (netbus, subseven) et que le frangin pique le cookies..). Il faut qu'il se tape la variable serveur... et si en plus t'a des variables sessions dans l'url là t'es tranquille !

Les failles ? Alors imaginons que la chauve-souris, elle imite la voix d'un copain ;-)

bien sûr si ton visiteur se fait piquer son mot de passe, ou si son mot de passe c'est "monchat", ou "monpoissonrouge" tu peux plus rien pour eux (surtout qu'à 80% des cas on est pas loin de ça). Et si tu te fais pirater ton accès ftp aussi... ou phpmyadmin...

Si tu couples le tout sur un https; c'est le pérou !

Rappel: faut pas vouloir ajouter un forum après sinon tu pleures

[Leonick]

Moi, j'ai fait une authentification htaccess/htpassword une fois que l'authentification est réussie, je n'ai plus besoin de vérifier le password, je ne me sert que du login et je vérifie les droits affectés à ce login dans la bdd.

Ce me permet comme cela de faire une authentification unique avec un forum.

[Prélude]

Il existe un système très usité pour craquer les .htaccess : le bruteforcing.

En gros, il s'agit de chercher toutes les combinaisons possible jusqu'à ce que la bonne passe (faut le faire un programme évidement).

Solution à cela : placer une durée entre 2 essais à chaque fois plus grande, genre :

recupere($temps);

sleep($temps);

$temps = $temps * 2;

stocke($temps);

Ce n'est qu'une solution de plus.

Mais il faut savoir que la plupart des piratages avec but de détruire ou de voler réellement viennent de l'interieur (mot de passe trop simple, logique, ou posé sur la table...)

[cvmh]

Merci pour toutes ces pistes et conseils.

J'étudie tout ça !

[destroyedlolo]

Il existe un système très usité pour craquer les .htaccess : le bruteforcing.

En gros, il s'agit de chercher toutes les combinaisons possible jusqu'à ce que la bonne passe (faut le faire un programme évidement).

Pour palier a ce genre d'attaque, une bonne solution est de mettre le compte en quarantaine si par exemple le mot de passe n'est pas entree correctement plus de X fois (3, 5, ...).

Pour le revalide, soit il est necessaire de faire une action :

- action de la part de l'admin du site (mais ca va vite le gaver),

- soit envoyer un EMail en demandant de cliquez sur un lien qui revalide le compte (c'est generalement ce qui est fait),

- soit le mettre en quarantaine pour une duree donnee.

Cependant, si le gas veut vraiment rentrer, il trouvera toujours une solution ...

[Leonick]

Pour palier a ce genre d'attaque, une bonne solution est de mettre le compte en quarantaine si par exemple le mot de passe n'est pas entree correctement plus de X fois (3, 5, ...).

du genre : je veux faire un beau DOS, je tente de me connecter en tant qu'admin jusqu'à ce que le compte soit bloqué

et je recommence avec tous les comptes modo

[destroyedlolo]

Arg, t'as de trop bonnes idees

Non, pour eux, c'est systematiquement un mail de revalidation.

Tien autre trucs qui me viens a l'esprit que j'ai vu sur un serveur FTP : en fait, ce n'est pas le compte qui est mis en quarantaine, mais l'IP d'ou vient l'attaque.

Evidement, ca n'evite pas les gros DoS avec moulte PC zombi, mais dans ces cas la, le reseau va s'effondrer bien avant que qq'un arrive a rentrer (j'ai deja eu la situation chez un client).

[Leonick]

Arg, t'as de trop bonnes idees

Tient autre trucs qui me viens a l'esprit que j'ai vu sur un serveur FTP : en fait, ce n'est pas le compte qui est mis en quarantaine, mais l'IP d'ou vient l'attaque.

et là encore, possibilité de faire un DOS pour les robots : je te fais une attaque en envoyer comme ip celles des spiders de google (je m'en fou que les requêtes ne me reviennent pas) donc après, tu te retrouves avec google blacklisté sur ton site. Et en moins de 1 semaine, ton site n'existe plus sur les moteurs de recherches

J'ai réfléchi à plein de scénarios possibles car je voudrais bloquer tous les hackers qui tentent de trouver des phpmyadmin, wordpress, mysql, etc... sur mes sites et ça n'est pas évident de faire de l'automatisation de blacklistage d'ip.

J'avais bloqué tous ces types d'attaques dans le htaccess et ensuite, je m'étais retrouvé avec des erreurs 403 dans l'interface webmaster de google, car certaines pages d'un annuaire contenaient "web" dans l'url et que je l'avais bloqué en htaccess