Sessions PHP sécurisées

Question

Ma question concerne la création d'une routine de connexion sécurisée. Après avoir comparé le nom d'utilisateur et le mot de passe aux valeurs stockées, j'ai défini une variable de session appelée log to true. Alors que l'utilisateur surfe autour de la page Web je vérifie juste la variable enregistrée pour vrai ou faux pour déterminer si l'utilisateur devrait avoir accès.

C'est la première fois que je crée quelque chose comme ça. Est-ce sécurisé? J'ai l'impression qu'il y a autre chose que je devrais faire pour m'assurer que les utilisateurs sont valides.

Answer 1

Toute personne qui obtient le cookie de session, est capable de se connecter comme vous. Si vous liez une session à une adresse IP, c'est beaucoup plus difficile. Mais cela peut vous donner des problèmes avec les personnes qui ont des adresses IP en train de changer. C'est à vous de décider si cela en vaut la peine.

Answer 2

Vous allez probablement vouloir stocker le nom d'utilisateur dans la session ainsi afin de personnaliser correctement toutes les pages pour l'utilisateur. Ce que vous avez décrit est "sécurisé" mais la sécurité de votre application est difficile à évaluer sans savoir ce que vous faites d'autre.

Answer 3

Bien sûr, c'est sûr, mais il y a des précautions à prendre pour éviter les situations/attaques non sécurisées.

Il n'y a aucun problème avec le mécanisme que vous avez décrit. Mais la mise en œuvre est incomplète/non spécifique. Vous devez considérer le stockage de mot de passe et les procédures que vous utiliserez pour vous connecter.

En réponse à une plainte, voici quelques questions OWASP soulève sur l'authentification/sessions.

1. Les informations d'identification sont-elles toujours protégées lorsqu'elles sont stockées à l'aide du hachage ou du cryptage?

Oui, stocker vos mots de passe des utilisateurs en tant que hash salés. 2. Les informations d'identification peuvent-elles être devinées ou remplacées par des fonctions de gestion de compte faibles (par exemple, création de compte, changement de mot de passe, récupération du mot de passe, identification de session faible)?

Non, ces fonctions devraient être protégées par un lien question de sécurité/email.

3. Sont exposés les ID de session dans l'URL (par exemple, la réécriture d'URL)?

Non, ils ne devraient pas l'être.

4. Les ID de session sont-ils vulnérables aux attaques de fixation de session?

Nope, ne permettent pas aux utilisateurs de définir leur identifiant de session par tout moyen en plus de connexion.

5. Les ID de session expirent-ils et les utilisateurs peuvent-ils se déconnecter?

Dans les cas où l'utilisateur n'a pas spécifié autrement "rester connecté pendant deux semaines", les sessions devraient expirer plus tôt.

6. Les ID de session sont-ils pivotés après une connexion réussie? Oui, l'utilisation de session_destroy() et de session_start() permettra d'atteindre cet objectif

7. sont-mots de passe, identifiants de session et d'autres informations d'identification envoyées uniquement sur les connexions TLS?

Bien sûr.

Finalement, vous devez considérer le type de données que vous allez gérer. Ne permettez jamais à quelqu'un d'avoir accès au mot de passe d'un utilisateur, car cela pourrait compromettre ses données ailleurs. Mais, si vous utilisez colorakitten.com, ne perdez pas le sommeil sur la possibilité de sessions détournées: "Oh non, quelqu'un a piraté mon compte et décoloré mes chatons."

Lire: PHP Session Security

Answer 4

Si vous ne traitez aucun type d'informations sensibles et essayez simplement de fournir une expérience utilisateur personnelle, ce que vous faites est très bien. Cependant, si vous êtes vraiment préoccupé par la sécurité, il existe plusieurs autres approches possibles. Le premier consiste à créer une table de base de données appelée "user_tokens" ou quelque chose de similaire. Lorsqu'un utilisateur se connecte, créez une clé aléatoire et stockez son adresse IP dans la table associée à la clé. En outre, stocker cette clé dans un cookie sur la machine des clients. Chaque fois qu'ils essaient de faire quelque chose de sensible, vous pouvez comparer leur adresse IP et la clé du cookie à celle de la base de données. Étudiez un peu le Cross-Site-Scripting (XSS) et le piratage de session. La méthode que j'ai décrite ci-dessus va vraiment réduire cela.