php: sécurisation des fonctions sensibles de la page

Question

Je suis novice en PHP et j'essaie de maîtriser la sécurité.

J'ai une page admin qui donne accès à certaines tâches administratives. À l'heure actuelle, il vous permet de repeupler les tables de base de données avec certaines données de base.

Pour accéder à la page d'administration, vous devez d'abord vous connecter. Actuellement, la connexion n'est pas terminée https (ce sera bientôt).

Si vous vous authentifiez, un jeton est écrit dans $ _SESSION. Dans chaque page d'administration, le jeton est vérifié. Si elle est invalide, la page est redirigée vers la page de connexion.

Ma question:

Est-ce la bonne façon de « verrouiller » les tâches administratives vers le bas sensibles en PHP? Vérification d'une valeur dans la variable $ _SESSION? Que devrais-je faire de plus?

Answer 1

C'est à peu près la façon standard de le faire. Authentifiez l'utilisateur par rapport à votre base de données utilisateur/mot de passe/autres données d'authentification, stockez l'état d'authentification dans une variable de session et vérifiez enfin si la variable de session est correctement définie chaque fois que l'utilisateur tente une action nécessitant une autorisation.

Answer 2

Les identifiants de session sont stockés côté client, généralement sous la forme d'un cookie. Si quelqu'un vole le cookie, ils peuvent détourner la session. Même si vous utilisez une connexion sécurisée pour la connexion, les demandes non sécurisées l'enverront par la suite, et toutes les vulnérabilités XSS peuvent être utilisées pour capturer le cookie de session, quelle que soit la communication cryptée. Utilisez session_set_cookie_params pour limiter le sous-domaine et le chemin des pages auxquelles le cookie est envoyé.

Vous pouvez essayer d'utiliser des données client non-spoofable pour détecter le piratage. Puisque vous n'avez aucun contrôle sur le protocole, les seules données de ce type sont l'adresse IP distante, bien qu'un attaquant puisse faire une attaque aveugle en usurpant son adresse IP. Cependant, cela ne protège pas contre les pirates de l'air derrière le même NAT que l'utilisateur valide et a des problèmes avec les requêtes par proxy.

Vous pourriez être en mesure d'élaborer quelque chose avec HTTP digest access authentication. C'est un protocole d'authentification challenge-response et donc conçu pour fonctionner sans cryptage au niveau du protocole. Cependant, il est basé sur MD5, qui a des faiblesses connues. Considérant la vie du défi, cela peut ne pas être un problème. Digest auth est vulnérable à une attaque man-in-the-middle.

Answer 3

Vous pouvez vous intéresser au rôle basé sur Access Control Lists si vous avez besoin d'un niveau de contrôle plus fin. De cette façon, les utilisateurs authentifiés se voient accorder ou refuser l'accès à certaines parties de votre application en fonction du rôle que vous leur avez attribué. Ceci est une mesure de sécurité supplémentaire en plus de l'authentification par mot de passe standard.

Si vous n'avez qu'un utilisateur, par ex. l'administrateur, l'ACL est exagéré cependant.