2010-04-08 7 views
2

J'ai créé une page de connexion et une page d'inscription et maintenant je veux l'utiliser pour protéger les pages par mot de passe et avoir des pages qui affichent des informations spécifiques à cet utilisateur.Système de connexion et sessions (php)

Le stockage de l'ID utilisateur de l'utilisateur connecté à une variable de session constituerait-il un moyen sûr et correct de le faire?

Dans quelle mesure serait-il facile pour un utilisateur de changer la variable de session pour un ID différent et d'accéder aux informations d'un autre utilisateur, sans avoir à taper les informations de connexion des utilisateurs?

EDIT: L'affichage de l'ID utilisateur de chaque page à la suivante serait-il plus sûr?

+0

Ne pas $ _POST quoi que ce soit !, encore moins l'ID utilisateur, c'est un trou de sécurité énorme. – Ben

+0

Je poste le mot de passe que l'utilisateur entre de la page d'index à la page de connexion, est-ce correct? –

+0

bien sûr c'est bien !!Si vous voulez plus de sécurité vous pouvez utiliser le cryptage de votre mot de passe, puis décrypter dans votre page de connexion – nik

Répondre

0

Bien que je ne suis pas au courant d'aucune façon dont un utilisateur peut manipuler les informations contenues dans $_SESSION à moins que votre code (ou code sur votre serveur) leur permet, donc ne fais rien de fou comme ...

foreach($_POST as $key=>$value) { // DON'T DO THIS 
    $_SESSION[$key] = $value; // DON'T DO THIS! 
} // WHY ARE YOU DOING THIS!? 

Vous ne devriez pas faire quelque chose comme ceci, où vous mettez simplement les données que l'utilisateur vous donne dans vos variables $_SESSION. Comme la base de données, l'écriture sur la session doit être considérée comme une forme de sortie, et vous devez désinfecter ce que vous y mettez (et où il est placé) en conséquence. Donc, à moins que vous ne fassiez quelque chose de fou comme ça (vous pourriez l'être, cela peut être beaucoup plus subtil), je ne pense pas que vous ayez à vous soucier d'un utilisateur qui change la variable de session. Vous pourriez avoir à vous soucier de la threats of a shared hosting environment où quelqu'un qui n'est probablement pas tout à fait un utilisateur final manipule les informations de session.

Ce qui n'est pas si sûr, c'est l'identificateur de session, car il y a quelques façons simples de hijack a session in PHP.

Je recommande de vérifier le livre auquel j'ai été lié, Essential PHP Secutiry. Il s'agit d'une explication très simple et directe (mais approfondie) de plusieurs concepts de base de la sécurité PHP, dont beaucoup peuvent être généralisés et doivent être gardés à l'esprit lors de tout travail de développement web.

1

Voici un

Si vous cryptez le nom d'utilisateur de telle sorte que seuls vos scripts PHP peuvent le déchiffrer, alors vous devriez être en sécurité, je suppose.

+0

Je n'allais stocker que l'ID utilisateur dans la session. –

0

Je vais parler du comportement de la session par défaut, ici: sessions sont basées sur un cookie « PHPSESSID » qui est réglé sur un MD5 Somme de contrôle (32 caractères alphanumériques). PHP accepte ce cookie du navigateur et l'utilise pour charger les données de session côté serveur. Le client n'a aucun moyen direct de modifier les données de la session, mais il peut spécifier son propre ID de session.

Vous pouvez ajouter des couches de sécurité supplémentaires (SSL, vérifier l'adresse IP du client, etc.), mais par défaut, si je connais votre cookie, je peux effectivement me connecter comme vous. En ce qui concerne la facilité, cela dépend de beaucoup d'autres niveaux de sécurité: quelqu'un renifle-t-il votre trafic, avez-vous installé un logiciel malveillant, etc.

Des outils comme Suhosin tentent d'améliorer la sécurité des sessions.

+0

Les adresses IP des clients changent souvent, ce qui signifie que les utilisateurs se font dire qu'ils sont des attaquants alors qu'ils ne le sont pas. –

+0

Suhosin (à titre d'exemple) peut limiter sa vérification au premier, deux ou trois octets. –