Discussion :

[Capie]

Bonjour,

Je souhaite mettre en place un système de back office pour un site. Cependant, je me demande comment en sécuriser l'accès. J'ai déjà créé le formulaire de connexion avec un captcha (+ pseudo et mdp).

Mais je n'arrive pas à imaginer un système simple qui permette de sécuriser l'ensemble:
- Est-ce mieux d'utiliser les sessions ou les cookies ?
- Quelle est la procédure à mettre en place pour identifier une personne (avec les infos en bdd) ? -
- Quelles informations stocker ?
- Comment sécuriser l'accès des autres pages du back office ?
- Si un admin quitte le site et qu'il y revient, comment vérifier que c'est lui sans lui redemander ses identifiants ?

Merci d'avance pour vos réponses.

[RunCodePhp]

Salut

Fait des recherche sur ne Net concernant une sécurisation/authentification avec le couple .htaccess et .htpasswd, c'est à mon sens nettement plus sécurisé que les sessions/cookie.

Il y a énormément d'infos, des tutos, etc ...

[alpha232]

Salut, pour sécuriser tes pages, un bon moyen c'est d'utiliser les sessions php.
Dans les grandes lignes,
Pour les informations à mémoriser, tout dépend des infos que tu as mis ds ta db pour l'utilisateur, mais en général on mémorise l'id de l'utilisateur, le niveau de privilège et parfois le nom d'utilisateur si besoin, dans des variables de session.
Ensuite sur chaque page à sécuriser, tu peux mettre tout au début, un code qui vérifie si les variables de session existent, sinon tu rediriges vers ta page de connexion.Si tu fermes le navigateur, tu perds les infos de session et donc ta connexion, à moins que tu n'aies enregistré de manière permanente les données des cookies de session.Pour éviter les risques dus à une situation où tu laisses le navigateur ouvert sur ta session, tu peux aussi inclure, un test , qui vérifie l'heure à laquelle la session a été ouverte, et ainsi définir un temps de session max en utilisation.

Alpha.

[Capie]

Merci pour vos réponses.

En fait, je pensais créer un cookie contenant une chaine aléatoire. Cette chaine, je l'enregistre dans une table, associée à l'id du membre, son pseudo, son ip et son heure de connexion.

A chaque chargement d'une page, je vérifie que le cookie existe. Si c'est le cas, je le renouvelle pour 72h après avoir vérifié que les infos sont cohérentes.

S'il ne revient pas pendant plus de 72h, le cookie est périmé et il doit se reconnecter.

Par contre s'il n'a pas coché la cache "se souvenir de moi", je crée une session qui contient exactement la même chose et qui elle, se supprime à la fermeture du navigateur.

Vous en pensez quoi ?

Ce que je ne comprends pas, c'est pourquoi il y a autant de données stockées en cookie sur developpez.net Tout le monde me dit que les cookies, c'est pas sécurisé et ici on en utilise plusieurs. J'ai cru voir mon mot de passe hasher et mon User ID. Mais ce n'est pas le seul site à le faire et j'aimerais comprendre comment ce système fonctionne et en quoi il est sécurisé.

Merci

[grunk]

Ce n'est que mon avis très personnel, mais les données d'un backoffice étant plus ou moins sensible , avoir une option "se souvenir de moi" n'est à mon sens pas une bonne idée.
Je pousserais même le vice à avoir une durée de session plutôt courte (en tout cas bien adaptée à l'utilisation du backoffice).
C'est certes un peu plus contraignant pour l'utilisateur mais ça évite les mauvaise surprise.

Pour augmenter la sécurité tu peux associé à chaque formulaire un "token" à durée de vie limitée. Qui t'assure que les données que recois ta page de taitement viens bien du bon formulaire. Une recherche sur protection csrf devrait te donner des résultats.

[Capie]

Oui en effet, la persistance de l'identification pendant 72h n'est pas correcte du tout pour un BO. Mais là, j'ai débordé sur un espace membres sans prévenir

A propos des failles CSRF, j'ai cherché un peu sur le net. En fait, si j'ai bien compris, ça consiste en l'exécution d'un script par un utilisateur qui n'est pas au courant. Pour la plupart, ça ne donne rien mais le danger vient des utilisateurs connectés au site. C'est bien ça ?

[grunk]

C'est bien ça ?

Oui c'est ca , en théorie voici ce que une attaque pourrait donner :

Dans ton admin tu as un script qui te permet de passer un utilisateur administrateur. Par exemple setAdmin.php?id=1456

Moi , vilain pirate je suis au courant que ce script existe. JE t'envoi par exemple un mail ou un message sur le forum avec un lien du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<a href="tonsite.com/tonscript.php?arg=argument"> Regarde ce lien !</a>

Naif que tu es , tu clic sur le lien qui :

1- Sans protection :
Va s'executer , et par exemple passer l'attaquant administrateur.

2- Avec protection :
Va vérifier que le token fournit correspond à celui enregistré dans ta session (qui est normalement généré par la page te menant au script). Le token ne correspondant pas (puisque impossible à trouver) le script ne s'ecutera pas.

Ce type de protection est intéressant à mettre en place sur des appel ajax même public , ca te permet d'être certains que c'est bien ton site qui fait l'appel et non un script distant par exemple

[Capie]

Ok, donc c'est quelque chose d'important surtout pour des scripts publics comme dans l'espace membre. Mais à ne pas négliger dans le back office.

Et pour la connexion à la partie admin du site je crée une session qui contient une chaîne, que j'associe avec une entrée dans la bdd. Et je peux aussi créer une session avec l'adresse IP et le navigateur pour être presque sûr de l'identité de l'utilisateur. C'est sécurisé comme ça ?

En ce qui concerne l'espace membres, je reprends le même schéma: session avec entrée en bdd. Et si la personne ne veut pas se reconnecter à chaque fois, je crée un cookie avec une autre chaine, associée dans la bdd avec le membre en question. Ce qui donne:
- Je me connecte et je veux rester identifié (session + cookie)
- Si je change de page, test sur la session et récupération des infos utiles en bdd
- Je quitte le site
- Je reviens: mon cookie existe et son contenu est comparé avec la chaine stockée en bdd (dans la table membres). C'est ok donc création d'une session. Sinon demande de connexion.

Qu'en penses-tu ? Merci

[grunk]

Si tu veux lier fortement tes session avec la base de données autant utiliser la bdd pour gérer les session directement , ça sera plus simple de cette manière.

Voir cet article pour un exemple : http://a-pellegrini.developpez.com/t...hp/session-db/

Le reste me semble correcte

[Capie]

J'avais lu cet article hier. Mais quelle est la différence avec ce que je propose ?

Le principe est de n'avoir qu'une seule variable de session contenant une chaine. Tu stockes cette chaine en bdd, associée à des infos sur l'utilisateur. Je me trompe ?

Qu'appelles-tu la gestion des sessions avec la bdd ?

[grunk]

A la différence du gestion de session classique avec la superglobale $_SESSION , ici tout se passe avec la bdd.
Comme dans ton cas tu souhaite utiliser la bdd pour stocker des infos de session autant ne pas utiliser du tout $_SESSION et reposer uniquement sur la base , comme dans l'article

[Capie]

Ah je viens de comprendre ! En fait, on appelle uniquement la fonction session_id() et c'est tout. Pas de création de $_SESSION.

T'en penses quoi de cette méthode ? C'est vraiment plus sécurisé que l'utilisation de sessions ?

[alpha232]

Salut,

Quand tu crée ta session(session_start()), l'id de session est créé.
Les données que tu décides de stocker dans tes variable $_SESSION sont stockées sur le serveur dans un dossier bien précis, sous forme de chaine (style user:nick;level:9; ), pas sur la machine de l'utilisateur, qui ne possède que l'id de session par lequel le serveur sait quelles données il doit renvoyer à l'utilisateur sous forme d'un tableau.
L'id de session est stocké sous forme de cookie sur la machine de l'utilisateur, sauf s'il a desactivé les cookies et alors l'id de session est passé dans l'url.


alpha.

[RunCodePhp]

Je vais insister un peu, car bien que les sessions ça sera très certainement utile, mais pour un backoffice, c'est à mon sens pas suffisant comme mécanisme de sécurité.

Si dans cet espace backoffice il y a des images, n'importe qui pourra visualiser cette image, y compris les fichier comme xml, css, javascript, etc ...
Voir même ceux en Php.
En fait, seul les fichier Php qui intègreront les code Php avec le mécanisme de session seront limités car là on demandera à ce qu'il y est eu une identification.

N'empêche que la sécurité repose sur Php, et sur certains fichiers Php, pas tous.
En somme, l'ensemble de cet espace n'est pas entièrement sécurisé, il y a des portes d'entrées si on peu dire.


En mettant en place une sécurité avec un .htaccess + .htpasswrd, c'est au niveau du serveur Web Apache que ça repose (et pas Php), et c'est ça qui fait que c'est nettement plus sécurisé.
Le principe est simple : il n'y a que 2 fichiers à créer, et on place le .htaccess dans le répertoire à protéger.
Ensuite, c'est absolument tout qui s'y trouve dans ce répertoire qui est automatiquement protégé, tous les fichiers/répertoires inclus en cascade.
Donc avec seulement 2 fichiers, on sécurise d'un coup tout un espace.

Pour ma part, c'est indispensable, du moins, c'est le minimum pour un backoffice, car les opérations effectuées sont la plupart irréversibles.


Les sessions c'est bien pour par exemple si on souhaite mettre des droits différents pour différents types d'admin, comme : superadmin, admin, éditeur, lecteurs, etc ...

[Capie]

@Alpha: merci d'avoir apporté ces précisions

@RunCodePhp: Si je comprends pas, d'après toi .htaccess et .htpasswrd suffisent pour la sécurité de l'admin. Les sessions / cookies ne servent qu'à gérer des droits entre les utilisateurs de ce back office. C'est bien ça ?

[RunCodePhp]

Si je comprends pas, d'après toi .htaccess et .htpasswrd suffisent pour la sécurité de l'admin. Les sessions / cookies ne servent qu'à gérer des droits entre les utilisateurs de ce back office. C'est bien ça ?

Oui, exactement.
Mais c'est mon avis (et c'est comme ça que je fais d'ailleurs).

Je t'invite à faire des recherches (genre protection .htaccess .htpasswrd dans GG).
Comme je l'ai dis auparavant, les infos foisonnent à ce sujet, c'est plus que courant, tu trouveras tout ce qu'il faut pour mettre ça en place.


Ensuite, pour ce qui est d'éviterde resaisir sans cesse les log/pass, à mon sens c'est se prendre le choux pour rien.
Au pire, il vaut mieux exploiter le navigateur pour ça, car n'importe quel navigateur aujourd'hui permet d'enregistrer des logd/pass automatiquement.
Mais c'est théoriquement à éviter.
(je ne le fait pas toujours, j'ai ai beaucoup trop.
A part la banque, les impots, des trucs comme ça où c'est trop sensible, je fais comme beaucoup, le navigateur les enregistre)

[Capie]

D'accord, merci. Je vais me renseigner à ce sujet

Et pour un espace membre, tu préconises quels moyens pour le sécuriser ?

[RunCodePhp]

Et pour un espace membre, tu préconises quels moyens pour le sécuriser ?

Avec les sessions, et log/pass dans la Bdd, c'est théoriquement suffisant.

[Capie]

Avec la méthode dont parle Grunk (mais avec sessions) ?
http://a-pellegrini.developpez.com/t...hp/session-db/

[grunk]

Je vais insister un peu, car bien que les sessions ça sera très certainement utile, mais pour un backoffice, c'est à mon sens pas suffisant comme mécanisme de sécurité.

Si dans cet espace backoffice il y a des images, n'importe qui pourra visualiser cette image, y compris les fichier comme xml, css, javascript, etc ...
Voir même ceux en Php.

Ca c'est un problème de structure de l'appli. En principe ta racine web ne contient que les fichiers ayant besoin d'être affichée. Donc les fichier php ne sont pas accessible (sauf un index.php). Il n'ya au final que le js/css/image qui le sont et qui ne présente donc aucun risque.

Perso j'ai jamais eu un client qui acceptait de se logguer 2x (une fois pour le htaccess , une autre fois pour la gestion de ses droits sur le backoffice).