Pourquoi le passage de l'ID de session en tant que paramètre d'URL n'est-il pas sûr?
J'ai récemment suivi une discussion, où une personne a déclaré que le passage de l'ID de session en tant que paramètre url n'était pas sûr et que les cookies devaient être utilisés à la place. L'autre personne a déclaré le contraire et a fait valoir que Paypal, par exemple, transmet l'identifiant de session comme paramètre url pour des raisons de sécurité.
Le passage de l'ID de session en tant que paramètre url est-il vraiment peu sûr? Pourquoi les cookies sont-ils plus sécurisés? Quelles sont les possibilités d'un attaquant pour les deux options (cookies et paramètre url)?
Le passage de l'ID de session en tant que paramètre d'URL n'est-il pas vraiment sûr?
Bien qu'il ne soit pas intrinsèquement peu sûr, cela peut être un problème à moins que le code ne soit très bien conçu.
Disons que je visite mon forum préféré. Il me connecte et ajoute mon ID de session à l'URL dans chaque demande. Je trouve un sujet particulièrement intéressant, et je copie et colle l'URL dans un message instantané à mon ami.
À moins que l'application n'ait pris des mesures pour s'assurer qu'il existe une forme de validation sur l'ID de session, l'ami qui a cliqué sur ce lien peut hériter de ma session, et serait alors capable de faire tout ce que je peux faire, comme moi.
En stockant les identifiants de session dans les cookies, vous éliminez complètement le problème de partage de lien.
Il existe une variante de ce thème appelée fixation de session , qui implique un partage intentionnel d'un identifiant de session à des fins malveillantes. L'article Wikipédia lié explique en détail le fonctionnement de cette attaque et en quoi elle diffère du partage non intentionnel de l'identifiant de session.
Pourquoi les cookies sont-ils plus sécurisés?
Les cookies peuvent être plus sécurisés ici, car ils ne sont pas quelque chose que les utilisateurs normaux peuvent copier et coller, ni même afficher et modifier. C'est un défaut beaucoup plus sûr.
Quelles sont les possibilités d'un attaquant pour les deux options?
Aucune de ces méthodes n'est à l'abri des attaques de l'homme du milieu sur une communication non chiffrée. Les modules complémentaires du navigateur, les logiciels espions et autres méchants côté client peuvent également espionner les deux méthodes de stockage des identifiants de session.
Dans les deux cas, la validation côté serveur que le client qui prétend posséder un ID de session est la meilleure pratique. La composition de cette validation est sujette à débat. Gardez à l'esprit que les utilisateurs derrière les proxys d'entreprise peuvent sauter entre les adresses IP entre les demandes, donc verrouiller une session sur une adresse IP peut aliéner accidentellement les gens. L'article fixation de session mentionne quelques autres alternatives utiles.
La plupart des sites Web stockent l'état de connexion de leur utilisateur dans la session, et si un attaquant a l'identifiant de session, il a également les privilèges de l'utilisateur connecté. En d'autres termes, les deux préoccupations de maintien de la session et d'authentification sont souvent couplées.
Un problème est que, il est facile de faire des attaques fixation de session . Dans ce cas, un attaquant enverrait une URL préparée avec un identifiant de session connu à l'utilisateur. Si l'utilisateur clique sur cette URL et établit une connexion, l'attaquant aurait une session avec des privilèges. Si le site Web nécessite un cookie, une URL préparée dans un e-mail ne suffira pas.
Si un site utilise HTTP mélangé avec HTTPS, l'ID serait transmis en clair dans l'URL pour toutes les demandes HTTP (même pour une demande d'image). Ainsi, si l'attaquant peut lire une seule requête HTTP après la connexion de l'utilisateur, il connaît l'identifiant de session.
Un moyen de sortir du problème serait de séparer les deux problèmes, en maintenant la session et l'authentification. Vous pouvez ensuite laisser l'ID de session non protégé, uniquement pour maintenir la session, et utiliser un cookie distinct pour vérifier l'état de connexion. Ce cookie doit être configuré pour être envoyé aux pages HTTPS uniquement.
En plus de ce que Charles et Martin ont dit, le fait de mettre quoi que ce soit dans l'URL augmente la probabilité de fuite. Cela peut se faire via un en-tête Referer dans une ressource liée, de l'accès au point de terminaison avec des enregistrements d'historique de navigateur, du reniflage de l'historique en force brute, des journaux Web protégés de manière inappropriée, etc. Il est donc généralement déconseillé de mettre tout ce que vous voulez garder secret dans une chaîne URL/requête.
Je n'ai pas vu Paypal utiliser des identifiants de session de serveur dans les URL. Il n'y a aucun moyen que ce soit vraiment plus sûr que les cookies; la raison pour laquelle cela était généralement fait dans le passé était de prendre en charge les navigateurs sans cookies activés. C'est de moins en moins une préoccupation ces jours-ci, et les problèmes d'utilisation de ne pas partager de liens, en plus des attaques de fixation de session, signifient que la session dans l'URL est généralement évitée aujourd'hui.
J'ai vu il y a quelques années que quelqu'un avait copié une URL (AVEC sessionid) sur Twitter. Tous les abonnés avaient alors un accès complet à ce compte de personnes sur ce site.
Alors oui, mettre un ID session dans l'URL est une mauvaise idée.