Un utilisateur ne peut-il pas modifier ses informations de session pour se faire passer pour d'autres?
Un attaquant ne peut-il pas simplement modifier ses informations de session (ou cookie car il est stocké localement) puis tromper le serveur qu'il est l'utilisateur légitime?
Supposons par exemple que si un site Web utilise l'identifiant de la base de données comme identifiant, l'attaquant se connecte à son compte pour obtenir son cookie. Ensuite, modifiez simplement son ID pour usurper l'identité d'un autre utilisateur légitime.
Oui, si vous pouvez deviner la clé de session d'un autre utilisateur, vous pouvez le devenir. C'est pourquoi vous devez disposer d'une clé de session imprévisible qui peut être révoquée.
Il y a eu des cas où les meilleures pratiques n'ont pas été suivies, par exemple Moonpig a produit une API qui a utilisé une clé de session qui était l'ID de l'utilisateur qui est défini lors de la création du compte comme un numéro consécutif. Cela signifiait que vous pouviez être n'importe quel utilisateur. Si cet utilisateur voulait vous arrêter, il ne pourrait pas, car c'est la clé de toutes les sessions dans lesquelles il est engagé et ne peut pas être changé car c'est l'ID unique pour lui dans la base de données Moonpig.
Ceci est un très bon exemple de la façon de le faire mal. Les clés de session doivent être imprévisibles et pouvoir être jetées (éventuellement un utilisateur peut avoir plusieurs clés de session).
Comme @Mindwin l'a mentionné dans les commentaires, la clé de session doit se trouver dans la charge utile HTTP (cookies ou données de formulaire [la meilleure pratique est dans les cookies]) et non dans l'URL. En effet, le fait d'avoir des données de session dans l'URL vous oblige à les mettre dans l'URL de chaque lien, vous empêche de persister une session si l'utilisateur quitte et revient, copiant l'URL et l'envoyant à quelqu'un lui donne votre session données et il y a une limite de caractères qu'une URL peut être.
Vous devez également utiliser HTTPS dans la mesure du possible afin qu'un attaquant ne puisse pas espionner la charge utile HTTP et obtenir une copie de la clé de session de cette façon (c'est ainsi que Firesheep a fonctionné).
Oui. Ça peut.
Les informations de session sont stockées côté serveur (à l'exception du jeton de session) tandis que les cookies de l'autre côté sont stockés côté client (navigateur). Ainsi, l'attaquant pourrait changer le jeton de session pour détourner une session.
L'attaque est communément appelée détournement de session par manipulation de cookies. Mais l'attaquant doit utiliser un token de session valide qui peut être trouvé facilement si un site est mal configuré. Un site mal configuré peut stocker un jeton dans l'URL, ou n'en génère pas au hasard etc ...
Voici quatre méthodes principales utilisées pour détourner une session:
- Fixation de session - Lorsque l'ID de session est accepté à partir de l'URL.
- Sidejacking de session - Lorsque l'attaquant peut voler le cookie de session par reniflement de paquets
- Cross-site scripting - Lorsque l'attaquant pirate l'ordinateur des utilisateurs pour exécuter un code qui est considéré comme fiable car il semble appartenir au serveur, permettant à l'attaquant d'obtenir une copie du cookie ou d'effectuer d'autres opérations.
- Malware - Peut détourner un navigateur pour voler ses fichiers de cookies à l'insu de l'utilisateur.
La meilleure pratique à protéger serait de stocker le jeton de session dans un cookie. Cependant, si le jeton de session ne correspond pas à des critères solides tels que le caractère aléatoire, l'unicité, la résistance à l'analyse statistique et cryptographique, il pourrait être possible pour un attaquant de manipuler la session.
Il semble y avoir une certaine confusion entre les cookies et les informations de session ici, alors commençons par les trier:
Les cookies sont stockés sur le client. L'utilisateur peut donc les modifier s'il le souhaite.
Les informations de session sont stockées sur le serveur. Cela signifie que l'utilisateur ne peut pas le modifier.
"Ne jamais faire confiance au client" est une ancienne règle de sécurité. Cela signifie que vous ne pouvez jamais faire confiance aux informations contenues dans les cookies - simplement parce que le cookie de nom d'utilisateur a la valeur "Alice" ne signifie pas que "Mallory" n'était pas celui qui s'est connecté.
Pour cette raison, les informations vitales ne sont généralement pas stockées dans des cookies sur le client mais plutôt dans la session sur le serveur. Vous utilisez ensuite un cookie avec un ID de session pour connecter les deux. L'ID de session est un long nombre aléatoire. Si l'ID de session Alice est 20349023490324 le serveur aura toutes ses informations de session (comme son nom d'utilisateur) classées sous ce numéro.
L'utilisateur peut changer l'ID de session, mais comme il y a tellement d'ID de session possibles, il est extrêmement peu probable qu'il devine un ID réellement connecté à un utilisateur.
Dans certains cas, vous souhaiterez peut-être de toute façon stocker des données dans des cookies. Pour empêcher l'utilisateur de jouer avec eux, vous pouvez le signer avec une clé que vous n'avez que sur le serveur. Étant donné que l'utilisateur n'a pas la clé, le serveur sera en mesure de détecter toute modification des cookies puisque la signature ne correspondra plus.
Les ID de session doivent être cryptographiquement sûrs dans le sens où vous ne pouvez pas simplement les deviner. Habituellement, c'est juste un nombre aléatoire de 128 bits et il n'a absolument aucune connexion évidente avec l'utilisateur qu'il identifie. Donc, pour imiter quelqu'un d'autre, vous devez trouver l'ID de cet utilisateur. Il existe des moyens de le faire, mais ils sont différents de "simplement le modifier" pour devenir quelqu'un d'autre.
Cependant, le serveur possède une table correspondant aux informations réelles de l'utilisateur et à l'ID de session appartenant à cet utilisateur afin qu'il puisse utiliser ces informations. Mais vous ne pouvez jamais connaître l'ID de session de quelqu'un d'autre simplement en regardant celui qui est stocké dans votre navigateur.
Tant de réponses semblent dire que si l'identifiant de session implique caractère aléatoire, unicité, résistance à l'analyse statistique et cryptographique ou quelque chose comme ça, alors ça va. Ce n'est pas vraiment vrai (car pas complet). Un cookie (qui contient cet identifiant) n'a pas à être deviné car il peut être littéralement intercepté et réutilisé par un attaquant. Il existe également des exemples rares mais possibles d'un système proxy ou pass-through dmz mélangeant des cookies (je l'ai vu). Pour cette raison, en plus de ce qui précède, vous souhaiterez probablement que votre application elle-même fasse quelque chose comme:
Lors de la connexion, le système stocke l'agent utilisateur et l'adresse IP de la demande dans la session côté serveur. Vérifiez toutes les demandes suivantes et vérifiez que les valeurs entrantes pour ip et user-agent correspondent à celles stockées dans la session. Sinon, invalidez la session côté serveur et redirigez vers l'écran de connexion. Cela empêchera le pirate de l'air d'entrer. Comme effet secondaire acceptable, l'utilisateur légitime sera également expulsé (uniquement lorsqu'une tentative de piratage se produit), mais il peut simplement se reconnecter.