27 votes

Les variables de session PHP sont-elles sûres?

J'ai un script de connexion, qui vérifie si un nom d'utilisateur/mot de passe contre des données dans une table 'user'. En outre, j'ai un rôle "sur table", qui spécifie le niveau d'accès d'un utilisateur donné. En supposant que je suis grâce à des scripts d'ouverture de session, il y a des failles de sécurité dans tout simplement effectuer une requête supplémentaire, si la connexion réussit, contre les "rôles" de la table de découvrir l'autorisation de l'utilisateur niveau et leur stockage dans une variable de session? L'idée serait alors que sur n'importe quelle page avec un mélange d'autorité, je pourrais simplement interroger la variable de session pour découvrir l'utilisateur connecté du niveau d'autorisation.

Merci.

40voto

Anthony Points 14424

Les séances sont nettement plus sûrs que, par exemple, les cookies. Mais il est toujours possible de voler une session et donc le hacker aura un accès total à tout ce qui est dans cette session. Certaines façons d'éviter cette IP, de contrôle (qui fonctionne très bien, mais est très faible fi gratuite et donc pas fiable sur son propre), et à l'aide d'un nonce. Généralement avec un nonce, vous disposez d'un par page "jeton" de sorte que chaque page vérifie que la dernière page du nonce correspond à ce qu'il a stocké.

Dans de vérification de sécurité, il y a une perte de la convivialité. Si vous n'IP de vérification et l'utilisateur se trouve derrière un pare-feu intranet (ou de toute autre situation qui provoque ce) qui ne tient pas une constante IP de l'utilisateur, ils vont avoir à se ré-authentifier à chaque fois qu'ils perdent leur propriété intellectuelle. Avec un nonce, vous obtenez toujours le fun "en Cliquant sur l'arrière de provoquer cette page pour briser" la situation.

Mais avec un cookie, un pirate peut voler la session en utilisant simplement assez simple XSS techniques. Si vous stockez de l'utilisateur, l'ID de session dans un cookie, ils sont vulnérables à cela aussi. Ainsi, même si la session n'est pénétrable à quelqu'un qui peut le faire au niveau du serveur hack (ce qui nécessite beaucoup plus de méthodes sophistiquées et généralement une certaine quantité de privilège, si votre serveur est sécurisé), vous avez encore besoin d'un niveau supplémentaire de vérification lors de chaque demande de script. Vous ne devriez pas utiliser des cookies et de l'AJAX ensemble, ce qui la rend un peu plus facile à totalement aller à la ville si le cookie n'est pas volé, que vos requêtes ajax ne peut pas obtenir les contrôles de sécurité sur chaque demande. Par exemple, si la page utilise un nonce, mais la page n'est jamais rechargé, le script ne peut être vérifier pour ce match. Et si le témoin est tenue de la méthode d'authentification, je peux maintenant aller à la ville de faire de mon méchanceté en utilisant le vol de cookie et l'AJAX trou.

9voto

ChiperSoft Points 524

Seuls les scripts d'exécution sur votre serveur d'accès à la _SESSION. Si vous définissez la portée du cookie de session, vous pouvez même restreindre à un répertoire spécifique. La seule façon de quelqu'un à côté de vous pourrait obtenir que les données de session consiste à injecter du code PHP dans une de vos pages.

Comme pour le système que vous utilisez, qui est acceptable et est un bon moyen de réduire les appels de base de données, mais gardez à l'esprit qu'il demandera à l'utilisateur de se déconnecter et reconnecter pour toute demande d'autorisation des modifications à appliquer. Donc si vous voulez verrouiller un compte et que l'utilisateur est déjà connecté, vous ne pouvez pas.

6voto

Brendan Berg Points 1024

Il convient de noter que dans Apache, PHP $_SESSION superglobale est accessible à l'ensemble des hôtes virtuels. Considérez le scénario suivant:

  • Votre serveur héberge deux domaines, example.com et instance.org. Sessions PHP sont stockées dans des cookies, qui sont limitées au domaine.
  • Un utilisateur se connecte à example.com et reçoit un IDENTIFIANT de session. Example.com définit quelques variables de session (qui sont stockés sur le serveur, pas dans le cookie).
  • Un tiers intercepte le cookie lors de la transmission et de la passe à instance.org. Instance.org a désormais accès à l'example.com les variables de session.

Ce n'est pas une grosse affaire quand vous contrôlez tous les hôtes virtuels sur votre serveur, mais si vous êtes partagée, sur une machine, c'est problématique.

2voto

Sean McSomething Points 4383

Si vous comptez sur une valeur stockée dans une variable de session pour déterminer les rôles alors vous perdez la possibilité de changer la valeur dans la base de données et qui reflètent l'encontre de l'utilisateur de la session en cours. Si vous regardez le Zend Framework, il y a une distinction claire entre l'authentification et l'autorisation, et musclé mises en garde dans le manuel de stocker uniquement la quantité minimale de données dans la session (c'est à dire "Ouais, il est l'utilisateur #37 et il connecté").

Autant que la sécurité va au - sauf si vous êtes sur le partage de l'hôte, il n'y a rien à craindre. Sur une configuré correctement partagée d'accueil, ils devraient être relativement sûr, trop.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X