Peut-on faire confiance aux sessions

Bonjour

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

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.

Dans 99 % des cas ? Une session peut ne pas être stockée sur le serveur ?

C'était pour ne pas dire 100% ;).

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.

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).

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).

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

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.

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.

Si quelqu'un intercepte le cookie, il pourra se faire passer pour l'utilisateur. Je pense que c'est là où se trouve la faille.

C'est plutôt difficile, quand même

Pas vraiment non…

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 ?

Premier exemple qui me vient à l'esprit : Un réseau WiFi public, et la connexion au site non sécurisé (i.e. en http).

Par ex : http://en.wikipedia.org/wiki/Firesheep

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

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.

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 !

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.

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 ?

Et-ce une bonne idée, à chaque requête, si connecté, de vérifier l'IP et l'User Agent ?

uniquement à but de statistique, l'user agent est totalement forgeable, la preuve.