Quelle est la meilleure façon d'éviter le détournement de session?

Plus précisément, cela concerne l'utilisation d'un cookie de session client pour identifier une session sur le serveur.

La meilleure réponse est-elle d'utiliser le cryptage SSL / HTTPS pour l'ensemble du site Web, et vous avez la meilleure garantie qu'aucun homme du milieu n'attaque ne pourra renifler un cookie de session client existant?

Et peut-être le deuxième meilleur pour utiliser une sorte de cryptage sur la valeur de session elle-même qui est stockée dans votre cookie de session?

Si un utilisateur malveillant a un accès physique à une machine, il peut toujours consulter le système de fichiers pour récupérer un cookie de session valide et l'utiliser pour détourner une session?

Le chiffrement de la valeur de session n'aura aucun effet. Le cookie de session est déjà une valeur arbitraire, le chiffrer ne fera que générer une autre valeur arbitraire qui peut être reniflée.

La seule vraie solution est HTTPS. Si vous ne souhaitez pas utiliser SSL sur l'ensemble de votre site (peut-être avez-vous des problèmes de performances), vous pourrez peut-être vous en sortir avec uniquement SSL protégeant les zones sensibles. Pour ce faire, assurez-vous d'abord que votre page de connexion est HTTPS. Lorsqu'un utilisateur se connecte, définissez un cookie sécurisé (ce qui signifie que le navigateur ne le transmettra que via un lien SSL) en plus du cookie de session normal. Ensuite, lorsqu'un utilisateur visite l'une de vos zones "sensibles", redirigez-le vers HTTPS et vérifiez la présence de ce cookie sécurisé. Un vrai utilisateur l'aura, pas un pirate de l'air de session.

EDIT : Cette réponse a été écrite à l'origine en 2008. Nous sommes en 2016 maintenant, et il n'y a aucune raison de ne pas avoir SSL sur l'ensemble de votre site. Fini le HTTP en clair!

Le SSL ne facilite que les attaques de reniflage. Si un attaquant a accès à votre machine, je suppose qu'il peut également copier votre cookie sécurisé.

À tout le moins, assurez-vous que les anciens cookies perdent leur valeur après un certain temps. Même une attaque de détournement réussie sera contrecarrée lorsque le cookie cessera de fonctionner. Si l'utilisateur a un cookie d'une session qui s'est connectée il y a plus d'un mois, faites-lui entrer à nouveau son mot de passe. Assurez-vous que chaque fois qu'un utilisateur clique sur le lien "déconnexion" de votre site, l'ancien UUID de session ne pourra plus jamais être utilisé.

Je ne sais pas si cette idée fonctionnera, mais voici: ajoutez un numéro de série dans votre cookie de session, peut-être une chaîne comme celle-ci:

SessionUUID, numéro de série, date / heure actuelle

Cryptez cette chaîne et utilisez-la comme cookie de session. Changez régulièrement le numéro de série - peut-être lorsque le cookie a 5 minutes, puis réémettez le cookie. Vous pouvez même le rééditer sur chaque page vue si vous le souhaitez. Du côté du serveur, gardez une trace du dernier numéro de série que vous avez émis pour cette session. Si quelqu'un envoie un cookie avec le mauvais numéro de série, cela signifie qu'un attaquant peut utiliser un cookie qu'il a intercepté plus tôt, invalidez donc l'UUID de session et demandez à l'utilisateur de saisir à nouveau son mot de passe, puis de réémettre un nouveau cookie.

N'oubliez pas que votre utilisateur peut avoir plus d'un ordinateur et qu'il peut donc avoir plus d'une session active. Ne faites rien qui les oblige à se reconnecter chaque fois qu'ils basculent entre les ordinateurs.

Avez-vous envisagé de lire un livre sur la sécurité PHP? Hautement recommandé.

J'ai eu beaucoup de succès avec la méthode suivante pour les sites non certifiés SSL.

1. Désactivez plusieurs sessions sous le même compte, en vous assurant de ne pas vérifier cela uniquement par adresse IP. Vérifiez plutôt par jeton généré lors de la connexion qui est stocké avec la session des utilisateurs dans la base de données, ainsi que l'adresse IP, HTTP_USER_AGENT et ainsi de suite

2. Utilisation d'hyperliens basés sur des relations Génère un lien (par exemple, http://example.com/secure.php?token=2349df98sdf98a9asdf8fas98df8 ) Le lien est ajouté avec une chaîne MD5 salée aléatoire x-BYTE (taille préférée), lors de la redirection de la page, la page générée aléatoirement token correspond à une page demandée.

   • Lors du rechargement, plusieurs vérifications sont effectuées.
   • Adresse IP d'origine
   • HTTP_USER_AGENT
   • Jeton de session
   • tu obtiens le point.

3. Cookie d'authentification de session courte durée de vie. comme indiqué ci-dessus, un cookie contenant une chaîne sécurisée, qui est l'une des références directes à la validité des sessions, est une bonne idée. Faites-le expirer toutes les x minutes, réémettez ce jeton et resynchronisez la session avec les nouvelles données. En cas de correspondance erronée dans les données, déconnectez l'utilisateur ou demandez-lui de ré-authentifier sa session.

Je ne suis en aucun cas un expert sur le sujet, j'ai eu un peu d'expérience dans ce sujet particulier, j'espère que cela aidera tout le monde.

// 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.
}

Cela permet de capturer des informations «contextuelles» sur la session de l'utilisateur, des informations qui ne devraient pas changer au cours de la vie d'une seule session. Un utilisateur ne sera pas à la fois devant un ordinateur aux États-Unis et en Chine, n'est-ce pas? Donc, si l'adresse IP change soudainement au cours de la même session, cela implique fortement une tentative de piratage de session, vous sécurisez la session en mettant fin à la session et en forçant l'utilisateur à s'authentifier à nouveau. Cela déjoue la tentative de piratage, l'attaquant est également obligé de se connecter au lieu d'accéder à la session. Avertissez l'utilisateur de la tentative (ajaxez-le un peu), et vola, l'utilisateur légèrement ennuyé + informé et sa session / information est protégée.

Nous ajoutons l'agent utilisateur et X-FORWARDED-FOR pour faire de notre mieux pour capturer l'unicité d'une session pour les systèmes derrière des proxies / réseaux. Vous pourrez peut-être utiliser plus d'informations que cela, n'hésitez pas à être créatif.

Ce n'est pas à 100%, mais c'est vraiment très efficace.

Vous pouvez faire plus pour protéger les sessions, les faire expirer, lorsqu'un utilisateur quitte un site Web et revient le forcer à se reconnecter peut-être. Vous pouvez détecter un utilisateur quittant et revenant en capturant un HTTP_REFERER vide (le domaine a été saisi dans la barre d'URL), ou vérifiez si la valeur de HTTP_REFERER est égale à votre domaine ou non (l'utilisateur a cliqué sur un lien externe / conçu pour accéder à votre site).

Expirez les sessions, ne les laissez pas rester valides indéfiniment.

Ne vous fiez pas aux cookies, ils peuvent être volés, c'est l'un des vecteurs d'attaque pour le détournement de session.

Essayez le protocole Secure Cookie décrit dans cet article par Liu, Kovacs, Huang et Gouda:

Comme indiqué dans le document:

Un protocole de cookie sécurisé qui s'exécute entre un client et un serveur doit fournir les quatre services suivants: authentification, confidentialité, intégrité et anti-relecture.

Quant à la facilité de déploiement:

En termes d'efficacité, notre protocole n'implique aucune recherche de base de données ni cryptographie à clé publique. En termes de déployabilité, notre protocole peut être facilement déployé sur un serveur Web existant et ne nécessite aucune modification de la spécification des cookies Internet.

En bref: il est sûr, léger, fonctionne pour moi tout simplement génial.

Il n'y a aucun moyen d'empêcher le piratage de session à 100%, mais avec une certaine approche, nous pouvons réduire le temps pour un attaquant de détourner la session.

Méthode pour éviter le détournement de session:

1 - utilisez toujours la session avec un certificat SSL;

2 - envoyer le cookie de session uniquement avec httponly défini sur true (empêcher javascript d'accéder au cookie de session)

2 - utilisez l'identifiant de régénération de session à la connexion et à la déconnexion (note: n'utilisez pas la régénération de session à chaque demande car si vous avez une requête ajax consécutive, vous avez la possibilité de créer plusieurs sessions.)

3 - Définissez un délai d'expiration de session

4 - stocker l'agent utilisateur du navigateur dans une variable $ _SESSION et comparer avec $ _SERVER ['HTTP_USER_AGENT'] à chaque requête

5 - définissez un cookie de jeton et définissez l'heure d'expiration de ce cookie sur 0 (jusqu'à ce que le navigateur soit fermé). Régénérez la valeur du cookie pour chaque requête (pour une requête ajax, ne régénérez pas le cookie de jeton). 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 pas régénérer le cookie de jeton avec la requête ajax note: le code ci-dessus est un exemple. Remarque: si les utilisateurs se déconnectent, le jeton de cookie doit être détruit ainsi que la session

6 - Ce n'est pas une bonne approche d'utiliser l'IP de l'utilisateur pour empêcher le piratage de session car certains utilisateurs changent d'IP à chaque demande. QUI AFFECTENT LES UTILISATEURS VALIDES

7 - Personnellement, je stocke les données de session dans la base de données, c'est à vous de décider quelle méthode vous adoptez

Si vous trouvez une erreur dans mon approche, veuillez me corriger. Si vous avez d'autres moyens d'empêcher l'hyjaking de session, veuillez me le dire.

Assurez-vous de ne pas utiliser de nombres entiers incrémentés pour les ID de session. Il est préférable d'utiliser un GUID ou une autre longue chaîne de caractères générée de manière aléatoire.

Il existe de nombreuses façons de créer une protection contre le piratage de session, mais toutes réduisent la satisfaction des utilisateurs ou ne sont pas sécurisées.

• Contrôles IP et / ou X-FORWARDED-FOR. Celles-ci fonctionnent et sont assez sécurisées ... mais imaginez la douleur des utilisateurs. Ils viennent dans un bureau avec WiFi, ils obtiennent une nouvelle adresse IP et perdent la session. Je dois vous reconnecter.

• Vérifications de l'agent utilisateur. Comme ci-dessus, la nouvelle version du navigateur est sortie et vous perdez une session. De plus, ceux-ci sont vraiment faciles à «pirater». Il est trivial pour les pirates d'envoyer de fausses chaînes UA.

• jeton localStorage. Lors de la connexion, générez un jeton, stockez-le dans le stockage du navigateur et stockez-le dans un cookie crypté (crypté côté serveur). Cela n'a aucun effet secondaire pour l'utilisateur (localStorage persiste pendant les mises à niveau du navigateur). Ce n'est pas aussi sûr - car ce n'est que la sécurité par l'obscurité. De plus, vous pouvez ajouter une logique (chiffrement / déchiffrement) à JS pour l'obscurcir davantage.

• Cookie réédité. C'est probablement la bonne façon de procéder. L'astuce consiste à n'autoriser qu'un seul client à utiliser un cookie à la fois. Ainsi, l'utilisateur actif aura un cookie réémis toutes les heures ou moins. L'ancien cookie est invalidé si un nouveau est émis. Les piratages sont toujours possibles, mais beaucoup plus difficiles à faire - un pirate informatique ou un utilisateur valide obtiendra l'accès refusé.

Considérons que pendant la phase de connexion le client et le serveur peuvent s'entendre sur une valeur de sel secrète. Ensuite, le serveur fournit une valeur de comptage à chaque mise à jour et s'attend à ce que le client réponde avec le hachage du (sel secret + nombre). Le pirate de l'air potentiel n'a aucun moyen d'obtenir cette valeur de sel secrète et ne peut donc pas générer le hachage suivant.

AFAIK l'objet de session n'est pas accessible chez le client, car il est stocké sur le serveur Web. Cependant, l'identifiant de session est stocké en tant que cookie et permet au serveur Web de suivre la session de l'utilisateur.

Pour empêcher le détournement de session à l'aide de l'ID de session, vous pouvez stocker une chaîne hachée à l'intérieur de l'objet de session, créée à l'aide d'une combinaison de deux attributs, adresse distante et port distant, accessibles sur le serveur Web à l'intérieur de l'objet de requête. Ces attributs lient la session utilisateur au navigateur dans lequel l'utilisateur s'est connecté.

Si l'utilisateur se connecte à partir d'un autre navigateur ou d'un mode incognito sur le même système, l'adresse IP restera la même, mais le port sera différent. Par conséquent, lors de l'accès à l'application, l'utilisateur se verrait attribuer un identifiant de session différent par le serveur Web.

Voici le code que j'ai implémenté et testé en copiant l'identifiant de session d'une session dans une autre. Cela fonctionne assez bien. S'il y a une échappatoire, dites-moi comment vous l'avez simulée.

@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é l'algorithme SHA-2 pour hacher la valeur en utilisant l'exemple donné à SHA-256 Hashing at baeldung

Attendant vos commentaires avec hâte.

Pour réduire le risque, vous pouvez également associer l'adresse IP d'origine à la session. De cette façon, un attaquant doit se trouver dans le même réseau privé pour pouvoir utiliser la session.

La vérification des en-têtes de référence peut également être une option, mais ceux-ci sont plus facilement usurpés.

Protéger par:

$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;