Peut-on faire confiance aux sessions

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour :D

Cela faisait longtemps que je n'étais pas venu sur le forum php (si on considère que ce site est la continuité du SdZ).

J'ai beaucoup travaillé avec un framework (symfony en l'occurrence) au point d'oublier les techniques d'authentification basiques en bon vieux php procédural.

Puis-je me permettre après la vérification de la connexion (des identifiants) de l'utilisateur de définir une variable de session à true pour considérer que l'utilisateur est connecté ? Ou il est facile pour un hacker de trafiquer ses variables de sessions et de passer au travers ? Sachant que les pages que je souhaite sécuriser ne sont pas non plus ultra-sensibles (du coup je ne suis pas sûr de la nécessité de passer par un token).

Merci pour vos réponses ;)

Édité par Coyote

+0 -0

Cette réponse a aidé l'auteur du sujet

Salut !

La session elle-même est un fichier stocké sur le serveur, donc tu peux faire confiance aux sessions, personne à part le serveur ne peut les modifier.

Par contre il faut se méfier des cookies, qui permettent d'ouvrir une session, car ceux-ci peuvent être modifiés par l'utilisateur.

+2 -0

Les sessions sont suffisamment sécurisés pour ça, car elle sont dans 99% des cas stockées sur le serveur et donc non modifiables par l'utilisateur, ce n'est pas le cas, par contre, pour les cookies.

« There was a kingdom that was falling so fast that people wouldn't help it, they wouldn't make it last » - Animal Kingdom, Beau

+0 -0

Je crois que c'est toujours stocké sur le serveur, par contre ça ne sera sûr qu'à 99 % (rien n'est sûr à 100 % de toute façon) car si pour une raison ou pour un autre on peut accéder à l'endroit où sont stockées les sessions, alors elles ne seront pas sûres. Mais bon par défaut ça n'est pas le cas.

+0 -0

Une session peut ne pas être stockée sur le serveur ?

Par défaut, Ruby on Rails passe par un cookie (chiffré), donc oui. On pourrait très bien faire de même avec PHP en créant son propre gestionnaire pour l'implémenter de la sorte (quoi que, ça ne doit pas trop s'y prêter).

Comme tout gestionnaire, c'est un choix (tout dépend de la sensibilité des données, du load balancing - ici, au moins t'es pas "emmerdé" puisque le client te renvoie carrément sa session, etc).

Édité par vibrice

+0 -0
Auteur du sujet

Merci ! Effectivement pour les cookies j'imagine que le mieux serait de réaliser une semi-authentification avec demande des informations de connexion pour les données sensibles (mais je ne l'implementerai pas dans mon cas).

;)

+0 -0

Pour les cookies, le plus souvent, on stocke le pseudo et le mot de passe chiffré.

« There was a kingdom that was falling so fast that people wouldn't help it, they wouldn't make it last » - Animal Kingdom, Beau

+0 -1

Pour les cookies, le plus souvent, on stocke le pseudo et le mot de passe chiffré.

Titi_Alone

Et le plus souvent, c'est une faille de sécurité assez énorme. :) Il ne faut rien stocker dans les cookies (enfin, pas d'info sensibles). L'info la plus sensible à stocker, ce serait un token de reconnexion qui change à chaque fois… Et encore, c'est pas le truc le plus sécurisé à faire.

Sinon oui, les sessions peuvent être stockées ailleurs qu'en natif (une bdd, des cookies, … etc), bien qu'en général la solution de base se suffise à elle-même.

"Meh." Outil de diff PHP : Totem

+0 -0

Ou est la faille ?

Si l'user modifie le pseudo, la connexion est impossible, s'il modifie le mot de passe, la connexion est impossible, au final, c’est comme s'il passait par le formulaire de connexion, mais avec les infos de stockés dans les cookies.

« There was a kingdom that was falling so fast that people wouldn't help it, they wouldn't make it last » - Animal Kingdom, Beau

+0 -0

Commet tu fait pour intercepter un cookie, toi ?

Obligation d’accéder à l'ordi de la personne ou de lui faire installer un script pirate / visiter un script pirate, non ?

Édité par Titi_Alone

« There was a kingdom that was falling so fast that people wouldn't help it, they wouldn't make it last » - Animal Kingdom, Beau

+0 -0

Certes, mais dans ce cas, vous faites comment pour garder quelqu'un connecté (sans utiliser les cookies?) ?

« There was a kingdom that was falling so fast that people wouldn't help it, they wouldn't make it last » - Animal Kingdom, Beau

+0 -0

Tu utilises la session à court terme, à long terme tu peux utiliser un cookie mais :

Tu ne stockes surtout pas les credentials de l'utilisateur. (mot de passe chiffré, ou quoi que ce soit qui permette de se logger directement)

Tu peux, comme l'a signalé Talus un peu plus haut, stocker un jeton de reconnexion contenant un hash d'informations sensibles de l'utilisateur (i.e. s'il change ces informations, le jeton sera de facto invalidé) et valable une seule fois. Quand il est utilisé, l'utilisateur reçoit un nouveau cookie avec un nouveau jeton de reconnexion automatique.

Le cookie "remember me" n'est utilisable que dans un temps raisonnablement court (une dizaine de jours) et donc (cf. au-dessus) une seule fois. Ça évite de sniffer tout plein de cookies et de se les garder sous le coude pour aller piquer l'identité des gens plus tard.

Ça n'empêche pas une personne d'intercepter un jeton et de s'en servir, malheureusement. Du coup :

Tu limites les informations disponibles lorsque l'utilisateur est authentifié via le cookie "remember me" : pas d'accès à des paiements, pas d'accès au changement de mot de passe, à ses infos personnelles, voire : aucun accès en écriture (un peu drastique).

Si un cookie de reconnexion est utilisé deux fois, tu envoies un mail à l'utilisateur : soit c'est lui qui vient à l'instant de visiter le site (i.e. se connecter) et son jeton a été intercepté et éventuellement utilisé et il ferait bien de se méfier. Soit ce n'est pas lui et tu lui demandes un login/mdp pour qu'il invalide illico presto la session en question.

C'est ce que font la plupart des services d'authentification automatique (hormis pour l'histoire des emails, que tu "raccroches" à la main par-dessus) comme Spring Security, base sur cet article.

Édité par Javier

Happiness is a warm puppy

+2 -0
Staff

Par défaut, Ruby on Rails passe par un cookie (chiffré), donc oui. On pourrait très bien faire de même avec PHP en créant son propre gestionnaire pour l'implémenter de la sorte (quoi que, ça ne doit pas trop s'y prêter).

Le cookie c'est l'identifiant de session, pas la session elle même !

Fonctionnement d'une session

Une session peut être (après beaucoup de travail et d'effort si l'identifiant n'est pas sécurisé, très facilement sinon) interceptée et donc usurpée et donc quelqu'un peut forcer le serveur à modifier une donnée en session. Donc a priori, on peut considérer les sessions comme des user input et donc appliquer le never trust user input.

Édité par artragis

+0 -0
Staff

Le sujet m'intéresse. Je suis en train de faire un système de sessions pour Node.js. Il n'y en a pas de base, donc faut le coder.

Niveau Node.js, vu que c'est une "application", je pense que le plus simple est de stocker les données dans un tableau associatif au sein de l'application (pour pas se faire chier avec des fichiers). Maintenant, si il y a bcp de sessions, ça risque de faire un beau gros tableau…

Et dans le cookies, juste l'id de session.

Et-ce une bonne idée, à chaque requête, si connecté, de vérifier l'IP et l'User Agent ? Lors de la première connexion, ces infos seraient gardées en mémoire (dans la tableau associatif). Si l'IP diffère ou que le navigo est différent, la session est supprimée. C'est pas la sécurité du siècle, mais ça peut être un plus. Non ?

Responsable de la validation - TodoFox - Le JavaScript, c'est bon, mais pas jQuery ! Séries

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte