Quelle est la meilleure façon de prévenir le détournement de session?
https://stackoverflow.com/questions/22880
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Plus précisément, cela est sujet à l'aide d'un client cookie de session pour identifier une session sur le serveur.
Est la meilleure réponse à utiliser le chiffrement SSL/HTTPS pour l'ensemble du site web, et vous avez la meilleure garantie de l'absence de l'homme dans le milieu des attaques sera en mesure de détecter un client existant cookie de session?
Et peut-être le deuxième meilleur d'utiliser une sorte de cryptage sur la valeur de session elle-même qui est stocké dans votre cookie de session?
Si un utilisateur malveillant a un accès physique à une machine, ils peuvent regarder encore le système de fichiers pour récupérer un cookie de session valide et l'utiliser pour détourner une session?
La solution
Chiffrement de la session de la valeur zéro effet.Le cookie de session est déjà une valeur arbitraire, le cryptage, il va tout simplement de générer une autre valeur arbitraire qui peut être reniflée.
La seule vraie solution est HTTPS.Si vous ne voulez pas faire du SSL sur votre site entier (peut-être vous avez des problèmes de rendement), vous pourriez être en mesure de s'en tirer avec seulement SSL protéger les zones sensibles.Pour ce faire, assurez-vous d'abord vous connecter à la page HTTPS.Lorsqu'un utilisateur se connecte, définir un cookie de sécurité (qui signifie que le navigateur ne fait que transmettre sur une liaison SSL), en plus de la session ordinaire de cookie.Ensuite, lorsqu'un utilisateur visite un de vos zones "sensibles", les rediriger vers HTTPS, et de vérifier la présence de cookie de sécurité.Un vrai utilisateur aura, une séance pirate de l'air ne sera pas.
MODIFIER:Cette réponse a été initialement écrit en 2008.C'est 2016 maintenant, et il n'y a aucune raison de ne pas avoir de SSL sur l'ensemble de votre site.Pas plus clair HTTP!
Autres conseils
Le SSL n'est utile que pour renifler les attaques.Si un attaquant a accès à votre machine, je vais supposer qu'ils peuvent copier votre cookie de sécurité aussi.
À tout le moins, assurez-vous que les anciens cookies perdent de leur valeur après un certain temps.Même un succès hijaking attaque seront contrecarrés quand le témoin s'arrête de fonctionner.Si l'utilisateur dispose d'un cookie à partir d'une session enregistré dans plus d'un mois, les faire saisir à nouveau son mot de passe.Assurez-vous que chaque fois qu'un utilisateur clique sur votre site lien "log out", que l'ancienne session UUID ne peut jamais être utilisé à nouveau.
Je ne sais pas si cette idée va fonctionner, mais va ici:Ajouter un numéro de série dans votre cookie de session, peut-être une chaîne de caractères comme ceci:
SessionUUID, Num De Série, Date/Heure Actuelle
Chiffrer cette chaîne et l'utiliser comme votre cookie de session.Changer régulièrement la série num - peut-être quand le témoin est de 5 minutes et puis relancez le cookie.On pourrait même émettre sur chaque page vue, si vous vouliez.Sur le côté serveur, garder une trace de la dernière série num que vous avez émis pour cette session.Si jamais quelqu'envoie un cookie avec le mauvais numéro de série, cela signifie qu'un attaquant peut-être l'aide d'un cookie ils ont intercepté plus tôt, afin d'invalider la session UUID et demander à l'utilisateur de saisir à nouveau son mot de passe, puis émettre un nouveau cookie.
Rappelez-vous que votre utilisateur peut avoir plus d'un ordinateur, de sorte qu'ils peuvent avoir plus d'une session active.Ne pas faire quelque chose qui les force à se connecter à nouveau à chaque fois qu'ils commuter entre les ordinateurs.
Avez-vous pensé à la lecture d'un livre sur le PHP de sécurité?Fortement recommandé.
J'ai eu beaucoup de succès avec la méthode suivante pour les non SSL des sites certifiés.
Dis-autoriser plusieurs sessions sous le même compte, vous assurant de ne pas vérifier ce uniquement par adresse IP.Plutôt vérifier par jeton généré lors de la connexion qui est stocké avec les utilisateurs de session dans la base de données, ainsi que l'adresse IP, HTTP_USER_AGENT et ainsi de suite
À l'aide de la Relation en fonction des liens hypertexte Génère un lien ( par exemple. http://example.com/secure.php?token=2349df98sdf98a9asdf8fas98df8 ) Le lien est ajouté avec un x-OCTETS ( taille par défaut ) aléatoire salé MD5 de la chaîne, sur la page de redirection générés aléatoirement jeton correspond à une page demandée.
- Lors de la recharger, plusieurs contrôles sont effectués.
- Adresse IP d'origine
- HTTP_USER_AGENT
- Jeton De Session
- vous obtenez le point.
Courte durée de Vie de la session cookie d'authentification.comme affiché ci-dessus, un cookie contenant une chaîne sécurisée, qui est l'une des références directes à des séances de validité est une bonne idée.Faire expirent toutes les x Minutes, de réviser le jeton, et re-syncing la session avec les nouvelles Données.Si tout sim-matches dans les données, soit à déconnecter l'utilisateur, ou de les faire ré-authentifier leur session.
Je suis pas un expert sur le sujet, je v il avait un peu d'expérience dans ce sujet, j'espère que certains de cette aide n'importe qui d'autre.
// Collect this information on every request
$aip = $_SERVER['REMOTE_ADDR'];
$bip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$agent = $_SERVER['HTTP_USER_AGENT'];
session_start();
// Do this each time the user successfully logs in.
$_SESSION['ident'] = hash("sha256", $aip . $bip . $agent);
// Do this every time the client makes a request to the server, after authenticating
$ident = hash("sha256", $aip . $bip . $agent);
if ($ident != $_SESSION['ident'])
{
end_session();
header("Location: login.php");
// add some fancy pants GET/POST var headers for login.php, that lets you
// know in the login page to notify the user of why they're being challenged
// for login again, etc.
}
Ce que cela ne fait capturer "contextuelle" informations sur la session de l'utilisateur, des éléments d'information qui ne devrait pas changer au cours de la vie d'une seule session.Un utilisateur ne va pas être à un ordinateur aux états-unis et en Chine dans le même temps, non?Donc, si l'adresse IP change tout à coup dans la même session qui implique fortement une session de tentative de détournement d'avion, de sorte que vous pouvez sécuriser la session par la fin de la séance et de forcer l'utilisateur à se ré-authentifier.Cette déjoue la tentative de hack, l'attaquant est aussi obligé de connexion au lieu de gagner l'accès à la session.Notifier l'utilisateur de la tentative d'ajax (un peu), et vola, un peu agacé+informé de l'utilisateur et de leur session/l'information est protégée.
Nous jeter dans de l'Agent Utilisateur et X-FORWARDED-FOR à faire de notre mieux pour capturer l'unicité d'une session pour les systèmes de derrière des proxys/réseaux.Vous pouvez être en mesure d'utiliser plus d'information, alors que, n'hésitez pas à être créatif.
Ce n'est pas à 100%, mais c'est sacrément efficace.
Il n'y a plus que vous pouvez faire pour protéger les sessions expirent, lorsqu'un utilisateur quitte un site web revient à les forcer à se connecter à nouveau peut-être.Vous pouvez détecter un utilisateur de partir et de revenir par la capture d'un vide HTTP_REFERER (domaine a été tapé dans la barre d'URL), ou vérifiez si la valeur dans le HTTP_REFERER est égal à votre domaine ou pas (l'utilisateur a cliqué sur un externe/conçu lien pour accéder à votre site).
Expiration des sessions, ne laissez pas les restent valables indéfiniment.
Ne pas compter sur les témoins, ils peuvent être volés, c'est l'un des vecteurs d'attaque pour détournement de session.
Essayez de Cookie de sécurité protocole décrit dans cette papier par Liu, Kovacs, Huang, et Gouda:
Comme indiqué dans le document:
Sécurisé cookie protocole qui fonctionne entre un client et un serveur doit fournir à la suite de quatre services:l'authentification, la confidentialité, l'intégrité et l'anti-replay.
Comme pour la facilité de déploiement:
En termes d'efficacité, notre protocole ne comporte pas de base de données de recherche ou cryptographie à clé publique.En termes de déploiement, notre protocole peut être facilement déployé sur un serveur web existant, et il ne nécessite pas de changement de les cookies Internet de spécication.
En bref:il est sécurisé, léger, fonctionne pour moi tout simplement génial.
Il n'y a aucun moyen de prévenir la session hijaking 100%, mais avec une approche peut-on réduire les temps pour un attaquant de hijaking la session.
Méthode pour éviter une session hijaking:
1 - toujours à la session d'utilisation avec certificat ssl;
2 - envoyer le cookie de session uniquement avec httponly définie sur true(éviter le javascript pour accéder à cookie de session)
2 - utilisation de la session de régénérer l'id de connexion et de déconnexion(note:ne pas utiliser de session régénérer à chaque demande parce que si vous avez consécutives à une requête ajax, alors vous avez une chance de créer de multiples session.)
3 - définir un délai d'expiration de session
4 - boutique de l'agent utilisateur du navigateur dans un $_SESSION variable comparer avec $_SERVER['HTTP_USER_AGENT'] à chaque demande
5 - définir un jeton de cookie ,et de régler la date d'expiration du cookie à 0(jusqu'à ce que le navigateur est fermé).Régénérer la valeur du cookie pour chaque demande.(Pour une requête ajax ne se régénèrent pas de jeton de cookie).EX:
//set a token cookie if one not exist
if(!isset($_COOKIE['user_token'])){
//generate a random string for cookie value
$cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));
//set a session variable with that random string
$_SESSION['user_token'] = $cookie_token;
//set cookie with rand value
setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
}
//set a sesison variable with request of www.example.com
if(!isset($_SESSION['request'])){
$_SESSION['request'] = -1;
}
//increment $_SESSION['request'] with 1 for each request at www.example.com
$_SESSION['request']++;
//verify if $_SESSION['user_token'] it's equal with $_COOKIE['user_token'] only for $_SESSION['request'] > 0
if($_SESSION['request'] > 0){
// if it's equal then regenerete value of token cookie if not then destroy_session
if($_SESSION['user_token'] === $_COOKIE['user_token']){
$cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));
$_SESSION['user_token'] = $cookie_token;
setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
}else{
//code for session_destroy
}
}
//prevent session hijaking with browser user agent
if(!isset($_SESSION['user_agent'])){
$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
}
if($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']){
die('session hijaking - user agent');
}
note:ne se régénèrent pas de jeton de cookie avec une requête ajax note:le code ci-dessus est un exemple.note:si les utilisateurs de déconnexion alors le cookie jeton doit être détruit ainsi qu'à la session
6 - il n'est pas une bonne approche pour utiliser l'ip de l'utilisateur pour la prévention de la session hijaking parce que certains utilisateurs ip change à chaque demande.QUI AFFECTENT LES UTILISATEURS VALIDES
7 - personnellement-je stocker les données de session dans la base de données , c'est à vous de savoir quelle méthode vous adopter
Si vous trouvez l'erreur dans ma démarche, merci de me corriger.Si vous avez plusieurs façons de prévenir la session hyjaking s'il vous plaît dites-moi.
S'assurer que vous n'utilisez pas incremting entiers pour les Id de session.Beaucoup mieux d'utiliser un GUID, ou certains autres généré de façon aléatoire chaîne de caractères.
Il existe de nombreuses façons de créer une protection contre les session détourner, cependant elles sont toutes, soit en réduisant la satisfaction de l'utilisateur ou ne sont pas sécurisés.
Propriété intellectuelle et/ou X-FORWARDED-POUR les contrôles.Ces travaux, et sont assez sécurisé...mais imaginer la douleur des utilisateurs.Ils viennent d'un bureau avec WiFi, ils obtenir une nouvelle adresse IP et perdre de la session.Ai connectez-vous à nouveau.
L'Agent utilisateur vérifie.Même que ci-dessus, la nouvelle version du navigateur n'est pas, et vous perdez une session.En outre, ce sont vraiment facile de "hack".Il est trivial pour les pirates pour envoyer de faux UA cordes.
localStorage jeton.Sur connectez-vous générer un jeton, de le stocker dans le navigateur de stockage et de les stocker dans cookie crypté (cryptées sur le serveur-côté).Cela n'a pas d'effets secondaires pour l'utilisateur (localStorage persiste à travers les mises à niveau du navigateur).Il n'est pas sûr - que c'est juste de la sécurité par l'obscurité.En plus, vous pouvez ajouter un peu de logique (cryptage/décryptage) JS à obscurcir encore davantage il.
Cookie réédition.C'est sans doute la bonne façon de le faire.L'astuce est de ne permettre à un client d'utiliser un cookie à la fois.Ainsi, l'utilisateur active aura cookie ré-émis toutes les heures ou moins.Vieux cookie est invalidée si le nouveau est émis.Hacks sont toujours possible, mais plus difficile à faire - soit pirate ou un utilisateur valide obtenez un accès rejeté.
Permettez-nous de considérer que, pendant la phase de procédure de connexion le client et le serveur peuvent s'entendre sur un secret de sel de valeur.Par la suite, le serveur fournit une valeur de décompte à chaque mise à jour et s'attend à ce que le client réponde avec le hash de la (secret sel + nombre).Le pirate n'a pas de moyen d'obtenir ce secret sel de la valeur et ne peut donc pas générer le prochain hachage.
Autant que je sache, l'objet de session n'est pas accessible au client, car il est stocké sur le serveur web.Toutefois, l'id de session est stocké dans un Cookie et il permet au serveur web de suivi de la session de l'utilisateur.
Afin de prévenir le détournement de session à l'aide de l'id de session, vous pouvez stocker un hachage de chaîne à l'intérieur de l'objet session, fait à l'aide d'une combinaison de deux attributs, adresse distante et le port distant, qui peut être consulté sur le serveur web à l'intérieur de l'objet de la requête.Ces attributs de la cravate de la session de l'utilisateur dans le navigateur lorsque l'utilisateur connecté.
Si l'utilisateur se connecte à partir d'un autre navigateur ou un mode incognito sur le même système, l'IP addr resterait le même, mais le port sera différent.Par conséquent, lors de l'accès à l'application, l'utilisateur serait une autre id de session par le serveur web.
Ci-dessous le code que j'ai mis en place et testé par la copie de l'id de session à partir d'une session à l'autre.Il fonctionne très bien.Si il y a une lacune, laissez-moi savoir comment vous simulées il.
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
HttpSession session = request.getSession();
String sessionKey = (String) session.getAttribute("sessionkey");
String remoteAddr = request.getRemoteAddr();
int remotePort = request.getRemotePort();
String sha256Hex = DigestUtils.sha256Hex(remoteAddr + remotePort);
if (sessionKey == null || sessionKey.isEmpty()) {
session.setAttribute("sessionkey", sha256Hex);
// save mapping to memory to track which user attempted
Application.userSessionMap.put(sha256Hex, remoteAddr + remotePort);
} else if (!sha256Hex.equals(sessionKey)) {
session.invalidate();
response.getWriter().append(Application.userSessionMap.get(sessionKey));
response.getWriter().append(" attempted to hijack session id ").append(request.getRequestedSessionId());
response.getWriter().append("of user ").append(Application.userSessionMap.get(sha256Hex));
return;
}
response.getWriter().append("Valid Session\n");
}
J'ai utilisé le SHA-2 l'algorithme de hachage de la valeur à l'aide de l'exemple donné à De Hachage SHA-256 à baeldung
Impatient de vos commentaires.
Pour réduire le risque, vous pouvez également associer l'IP d'origine avec la session.De cette façon, un attaquant doit être dans le même réseau privé pour être en mesure d'utiliser la session.
Vérification referer en-têtes peut également être une option, mais ceux-ci sont plus facilement usurpée.
Protéger par:
$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;
