La transmission de l'identifiant de session en tant que paramètre d'URL n'est-elle vraiment pas sécurisée?

Bien que ce ne soit pas intrinsèquement non sécurisé, cela peut poser 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 identifiant de session à l'URL dans chaque demande. Je trouve un sujet particulièrement intéressant, et copie & collez 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'identifiant de session, l'ami qui a cliqué sur ce lien peut hériter de ma session, et pourra alors faire tout ce que je peux faire, comme moi.

En stockant des identifiants de session dans des 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 pour à des fins malveillantes. L'article Wikipédia lié explique en détail comment cette attaque fonctionne et en quoi elle diffère du partage involontaire de l'identifiant de session.

Pourquoi les cookies sont-ils plus sécurisés?

Les cookies peuvent être plus sûrs ici, car ils ne sont pas quelque chose que les utilisateurs normaux peuvent copier coller &, ou même afficher et modifier. C'est une valeur par défaut beaucoup plus sûre.

Quelles sont les possibilités d'un attaquant pour les deux options?

Aucune de ces méthodes est à l'abri des attaques de type «man-in-the-middle» via une communication non chiffrée. Les addons de 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 une bonne pratique. Le contenu de cette validation est sujet à débat. Gardez à l'esprit que les utilisateurs derrière des proxys d'entreprise peuvent sauter entre les adresses IP entre les demandes, de sorte que le verrouillage d'une session sur une adresse IP peut accidentellement aliéner des personnes. L'article sur la 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'ID de session, il a également les privilèges de l'utilisateur connecté. En d'autres termes, les deux soucis de maintien de la session et d'authentification sont souvent associés.

Un problème est qu'il est facile de faire des attaques de 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 se connecte, l'attaquant aura une session avec des privilèges. Si le site Web nécessite un cookie, alors une URL préparée dans un e-mail ne sera pas suffisante.

Si un site utilise HTTP mélangé avec HTTPS, l'ID sera transmis en texte brut dans l'URL pour toutes les requêtes HTTP (même pour une demande d'image). Donc, si l'attaquant peut lire une seule requête HTTP après que l'utilisateur s'est connecté, il connaît l'identifiant de la session.

Un moyen de sortir du problème serait de séparer les deux problèmes, maintenir la session et l'authentification. Vous pouvez alors laisser l'identifiant de session sans protection, uniquement pour maintenir la session, et utiliser un cookie séparé pour vérifier l'état de connexion. Ce cookie doit être configuré pour être envoyé uniquement aux pages HTTPS.

En plus de ce que Charles et Martin ont dit, mettre quoi que ce soit dans l'URL augmente le risque 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 du navigateur, de la détection de l'historique de 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 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 de nos jours, et les problèmes d'utilisabilité de ne pas être de partager des liens, en plus des attaques de fixation de session, signifient que la session dans l'URL est généralement évitée aujourd'hui.

Quelque chose que j'ai vu il y a quelques années, c'est que quelqu'un a copié une URL (AVEC sessionid) dans Twitter. Tous les abonnés avaient alors un accès complet à ce compte de personnes sur ce site.

Donc oui, mettre un sessionID dans l'URL est une mauvaise idée.

L'ID de session ajoute à la sécurité lorsque des cookies sont déjà utilisés. Imaginez s'il existe un lien qui transfère de l'argent de votre banque:

https://mybank.com/transferMoney?sum=10000&destAccount=someAccount

Si vous comptez uniquement sur les cookies, ce lien peut vous être fourni dans un e-mail frauduleux. Lorsque vous l'ouvrez et cliquez sur ce lien, puisque vous avez un cookie dans votre navigateur, il sera réellement fonctionnel. Vous allez réussir (et involontairement) à transférer de l'argent de votre compte vers celui de quelqu'un d'autre.

Si le lien était:

https://mybank.com/transferMoney?sum = 10000&destAccount = someAccount&sessionId = jow8082345hnfn9234

alors un fraudeur malveillant n'a pas pu vous envoyer l'e-mail comme celui ci-dessus car il est presque impossible de deviner votre ID de session actuel.