Méthodes de contournement de session piratage

Question

Il est assez évident que la plupart d'entre nous programmeurs PHP ne veulent pas que notre travail publié soit piraté ou exploité d'une manière que nous n'avions pas l'intention. Je suis donc très prudent en demandant des moyens de contrer le détournement de session. Je sais qu'il y a la fonction session_regenerate_id() pour contrer partiellement le détournement de session mais j'étais plus curieux d'une autre méthode que j'ai trouvée:

En tant qu'utilisateur se connecte au site, vous prenez son user_id (ou un autre encore plus secret, prédéfini chaîne cryptée) (qui est inconnue pour les utilisateurs communs) sous forme de chaîne et vous la saliez avec des symboles prédéfinis aléatoires, md5() la chaîne et le définissez comme $ _SESSION ['code_utilisateur'] = $ chaîne_string; et chaque fois que cet utilisateur accède à une page, vous répétez la procédure et faites correspondre avec $ _SESSION ['user_code'], s'ils ne correspondent pas; détruire la session.

donc dans le code, il ressemblerait à quelque chose comme ceci (par exemple):

//user credentials are correct, user data is fetched from db 

$_SESSION['username'] = $row[3]; //username 
$_SESSION['password'] = $row[2]; //password 
$_SESSION['user_id'] = $row[4]; //user_id 
$salt1 = 'uNs819'; 
$salt2 = 'J2i'; 
$user_code = $salt1 . $row[4] . $salt2; 
$user_code = md5($user_code); 
$_SESSION['user_code'] = $user_code; 

Et vous vérifiez si cela est correct au début de chaque page disponible avec:

//fetch user credentials from db again 
//$row4 is the user_id 
if($_SESSION['user_code'] != md5($salt1 . $row[4] . $salt2){ 
    session_destroy(); 
} 

I ne pense pas que l'utilisation de l'id_utilisateur dans le cadre du chiffrement est optimale, mais ce n'est qu'un exemple. De préférence j'utiliserai une chaîne md5 de l'horodatage de quand l'utilisateur a été créé. Mais si je n'étais pas clair, ma question principale est que cette méthode est solide contre le détournement de session, pourquoi/pourquoi pas?

Answer 1

Toujours vérifier toute forme contre un jeton de faux cross-site, par exemple, lors de la connexion à créer un jeton:

Session:set('token', md5(uniqid()); 

ensuite sur chaque lieu sous forme d'une entrée de forme cachée avec ledit jeton

<input type="hidden" name="crsf" value="<?php echo System::escape(Session::get('token'));"> 

Ensuite, vous pouvez les vérifier pour vous assurer:

if(Request::post('crsf') == Session::get('token'): 
    //do what you gotta do 

assurez-vous regénérer un nouveau jeton Je m'excuse d'utiliser des méthodes pour cela, mais vous obtenez l'essentiel pour savoir comment gérer les formulaires et quoi d'autre.

Answer 2

"Une autre méthode que j'ai trouvée" - veuillez citer vos sources. Ce que vous décrivez ici ne fait absolument rien pour influencer le détournement de session. Peu importe le nombre de valeurs de session, le nombre de sels et le nombre de cycles de cryptage utilisés, le résultat correspondra toujours. Si la session est compromise, vous ne pouvez pas vous en servir pour vérifier la session. La fonction session_regenerate_id() ajoute une petite valeur mais ne fait que réduire la fenêtre d'une vulnérabilité existante à exploiter. Passez votre temps à éviter les compromissions de session - utilisez https, HSTS, http-only + indicateurs de cookie sécurisés, un CSP strict, destruction de session à l'expiration.

Si vous ressentez vraiment le besoin d'améliorer encore la sécurité, utilisez un jeton avec l'échange normal, par ex. une réponse de défi utilisant le stockage local ou l'empreinte digitale de dispositif.

Answer 3

Vous n'avez pas besoin d'un schéma de fantaisie avec plusieurs sels.

De plus, si je peux voler le cookie de session d'un utilisateur, votre système ne fonctionnera pas du tout.

1. Modifier l'identifiant de session après la connexion pour éviter la fixation de session

2. Utilisez HTTPS partout

3. Utiliser cookie de session httpOnly si JavaScript ne peut pas lire

4. Valider et rejeter l'entrée XSS et échapper les données générées par l'utilisateur sur la sortie

5. Utilisez un long, id session aléatoire

6. utilisateur Reauthenticate pour les opérations importantes