Je connais tous les problèmes avec la fixation de la session et le détournement. Ma question est vraiment basique: je souhaite créer un système d'authentification avec PHP. Pour cela, après le login, je stockerais simplement l'ID utilisateur dans la session.
Mais: j'ai vu certaines personnes font des choses étranges comme générer un GUID pour chaque utilisateur et chaque session et stocker cela au lieu de simplement l'ID utilisateur de la session. Pourquoi?
Le contenu d'une session ne peut pas être obtenu par un client - ou peut-il?
4 Réponses :
Vous êtes correct. Le client vient de voir un jeton de session généré au hasard. Il y a des façons que ce jeton puisse être mal utilisé (détourné, etc.), mais avoir un GUID sur le dessus ne ajoute rien. En revanche, des options telles que session.cookie_httparly (JavaScript ne peut pas voir la session Cookie) Session .Cookie_secure (Cookie ne peut être transmis que sur HTTPS) Protéger contre certains scénarios d'attaque.
Parfois, pour une sécurité supplémentaire, les développeurs peuvent affecter une longue chaîne à la session de l'utilisateur afin de rendre le détournement encore plus difficile. En définissant un cookie avec cette nouvelle chaîne au moment de la création de session, l'application peut vérifier la chaîne correcte sur les demandes suivantes afin de mieux vous assurer qu'elle est la personne qui s'est réellement connectée.
Il suffit d'ajouter une autre chose qu'un pirate d'air de Wannabe devrait deviner. Cependant, cela peut être un faux sentiment de sécurité car il ne peut guère protéger la session si renifler est impliqué car le nouveau cookie est envoyé avec le cookie de session PHP. En outre, les identifiants de session sont très difficiles à deviner que cela (comme je suis sûr que vous savez, ne le placez pas dans l'URL, mais plutôt dans le cookie).
Informations sur la session est stockée sur le disque dur afin que cela ne soit pas obtenu par des clients sans intervention d'application.
Je ne comprends pas comment cela devrait améliorer la sécurité: si un pirate informatique tire ses mains sur les en-têtes HTTP de quelqu'un d'autre, il va simplement copier tout l'en-tête de cookie - et il va. Comment un pirate informatique devrait-il obtenir un identifiant de session sans renifler?
C'est pourquoi j'ai dit: "Il ne fait que protéger la session si renifler est impliqué parce que le nouveau cookie est envoyé juste avec le cookie de session PHP." J'ai édité pour ajouter du "faux sens de la sécurité" pour conduire le point à la maison.
@ewolf Vous pouvez obtenir un identifiant de session sans renifler dans des scénarios stupides où la session est envoyée via Get et non via Post: lorsque l'utilisateur copie l'URL et la colle quelque part, il a donné son identifiant de session. Quoi qu'il en soit, cela n'est pas pertinent.
Pour ajouter à Ewolf, ils peuvent aussi essayer de la brute la force.
Je n'ai jamais vu des Guids utilisés pour des sessions, mais il y a quelques méthodes supplémentaires que j'ai vues que cela ajoutent un peu plus de sécurité.
Il y a un excellent article sur Séance de détournement des contre-mesures sur Wikipedia, en fait.
Cela étant dit, j'imagine que quiconque stocke une solution dans le cadre d'une session à utiliser dans la sécurité de la session pourrait ne pas voir une meilleure solution (telle que la régénération de la session). Je peux voir d'autres utilisations pour qu'un GUID soit stocké (peut-être que cela fait partie d'un générateur aléatoire pour un jeu), mais pas à utiliser avec la sécurité de la session.
Juste pour ajouter, il y a des gens avec des Isp malheureux qui changent souvent de leur adresse IP (parfois toutes les quelques minutes!) Donc, l'enveloppement de la propriété intellectuelle dans la session peut causer trop de maux de tête.
@webbridave - Ouais, je ne l'utilise pas à moins d'une raison vraiment bonne raison. Il y a beaucoup de raisons de ne pas l'utiliser que si vous êtes prêt à accepter les problèmes qui l'accompagnent.
Http_user_agent fournit une protection zéro contre toute attaque car elle est une variable contrôlée par l'utilisateur.
@Le Rook - Évidemment, il s'agit d'une variable contrôlée par l'utilisateur et vous seriez confondre à compter sur elle. Cependant, vous pouvez l'utiliser comme indicateur que quelque chose a changé entre la dernière fois que vous avez vu l'ID de la session et cette fois et forcez une régénération de session. L'ID de session est également une variable contrôlée par l'utilisateur, mais je ne vous vois pas de mentionner cela. La sécurité de la session est des couches d'hypothèses et vous ne pouvez pas avoir une véritable sécurité sans crypter la totalité de la transmission.
Mettre l'évidence de côté. Je pense qu'il est préjudiciable de recommander aux gens de mettre en œuvre des systèmes de secuirty qui sont triviaux à contourner. Peut-être ne réalisez-vous pas à quel point il est facile de tromper un tel système addons.mozilla .org / fr-nous / firefox / addon / 59 . Gardez également à l'esprit que si l'attaquant utilise XSS ou renifler la ligne, ils pourront voir l'agent utilisateur dans l'en-tête HTTP.
Vérification de l'agent utilisateur est une forme de EN.Wikipedia.org/wiki/security_through_obscurité et je ' ll laisser le débat à cela.
@Le Rook - Si l'attaquant renifle ou utilise des XSS, ils ont déjà reçu votre identifiant de session et tout le reste est discutable. Si vous allez faire cette hypothèse, il est inutile de parler de toute autre mesure que SSL.
@zombat, je suis heureux de vous entendre dire que, maintenant, que diriez-vous de modifier votre message? Ou pouvez-vous penser à tout cas où un attaquant aura l'ID de la session et non l'agent utilisateur?
La réponse courte est que $ _Session est Le contenu de la session n'est pas normalement accessible à l'utilisateur. Vous devriez être capable de stocker la clé primaire de l'utilisateur et tout ira bien. Il existe des cas où la session peut être divulguée sur un système Linux normal, le dossier de session est IN / TMP, mais cela pourrait être modifié dans votre PHP.ini vers la racine Web (/ var / www / tmp), puis pourrait être accessible. . Le seul autre moyen est que l'utilisateur est capable d'accéder au Super Global $ _session en détournant un appel à Eval () ou de la variable étant imprimée normalement.
Si vous exécutez sur un hôte partagé et que vous utilisez une ancienne version de PHP et / ou votre serveur est mal configuré, il peut être possible de lire un autre utilisateur de ce système de lire ou même de modifier un fichier de session stocké dans / TMP /. Je ne connais pas une seule application qui prend cette attaque en considération. S'il s'agit d'un problème, vous pouvez stocker les informations dans une table dans la base de données.