Mon application Web utilise UserId presque toute la totalité de l'application ..Quel est le moyen efficace pour sécuriser une variable de session en PHP?
ce qui est la façon la plus efficace d'obtenir une variable de session en php?
La session est-elle vulnérable aux attaques?
Devrais-je conserver ma valeur chiffrée de UserId en session?
Toute suggestion ...
Note: de Taken my previous answer.
Afin de comprendre comment rendre votre session sécurisée, vous devez d'abord comprendre comment les sessions.
Voyons voir ce morceau de code:
session_start();
Dès que vous appelez cela, PHP recherchera un cookie appelé PHPSESSID (par défaut). Si elle ne se trouve pas, cela va créer un:
PHPSESSID=h8p6eoh3djplmnum2f696e4vq3
Si on le trouve, il prend la valeur de PHPSESSID et charge la session correspondante. Cette valeur est appelée session_id.
C'est la seule chose que le client saura. Tout ce que vous ajoutez dans la variable de session reste sur le serveur et n'est jamais transféré au client. Cette variable ne change pas si vous modifiez le contenu de $_SESSION. Il reste toujours le même jusqu'à ce que vous le détruisiez ou que cela expire. Par conséquent, il est inutile d'essayer d'obscurcir le contenu de $_SESSION en le hachant ou par d'autres moyens que le client ne reçoit jamais ou envoie cette information.
Ensuite, dans le cas d'une nouvelle session, vous définissez les variables:
$_SESSION['user'] = 'someuser';
Le client ne verra jamais cette information.
Un problème de sécurité peut se produire lorsqu'un utilisateur malveillant vole la session_id d'un autre utilisateur. Sans une sorte de vérification, il sera libre d'usurper l'identité de cet utilisateur.Nous devons trouver un moyen d'identifier le client de manière unique (pas l'utilisateur). Une stratégie (la plus efficace) consiste à vérifier si l'adresse IP du client qui a démarré la session est la même que l'adresse IP de la personne qui utilise la session.
if(logging_in()) {
$_SESSION['user'] = 'someuser';
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}
// The Check on subsequent load
if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
die('Session MAY have been hijacked');
}
Le problème avec cette stratégie est que si un client utilise un équilibreur de charge, ou (sur une longue session de durée), l'utilisateur dispose d'une adresse IP dynamique, il déclenche une fausse alerte.
Une autre stratégie consiste à vérifier l'agent utilisateur du client:
if(logging_in()) {
$_SESSION['user'] = 'someuser';
$_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT'];
}
// The Check on subsequent load
if($_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT']) {
die('Session MAY have been hijacked');
}
L'inconvénient de cette stratégie est que si les mises à jour du client, il est navigateur ou installe un addon (certains ajoute à l'agent utilisateur), la chaîne user-agent change et déclenche une fausse alerte.
Une autre stratégie consiste à faire tourner le session_id sur chaque 5 demandes. De cette façon, le session_id ne reste théoriquement pas assez longtemps pour être piraté.
if(logging_in()) {
$_SESSION['user'] = 'someuser';
$_SESSION['count'] = 5;
}
// The Check on subsequent load
if(($_SESSION['count'] -= 1) == 0) {
session_regenerate_id();
$_SESSION['count'] = 5;
}
Vous pouvez combiner chacune de ces stratégies comme vous le souhaitez, mais vous combinerez également les inconvénients.
Malheureusement, aucune solution n'est infaillible. Si votre session_id est compromise, vous êtes à peu près fini. Les stratégies ci-dessus ne sont que des mesures d'interruption.