Sécurité de piratage de session

J'ai donc plusieurs façons d'essayer d'empêcher le piratage de session, l'une utilise le HTTP_USER_AGENT et détecte si elle a changé au cours d'une session. Le problème est, si un utilisateur se connecte au site sur un téléphone mobile, et les changements de la vue mobile à une vue de bureau, les changements de l'agent utilisateur et l'utilisateur obtient l'erreur suivante:Sécurité de piratage de session

if (isset($_SESSION['HTTP_USER_AGENT'])) 
{ 
    if ($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT'])) 
    { 
     echo "Error: security issue #1 (Please use contact us if recieving this error)"; 
     exit; 
    } 
} 
else 
{ 
    $_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']); 
}

Maintenant, je Je veux toujours cette petite couche de sécurité, mais je ne veux pas qu'un message d'erreur apparaisse et je veux que le site reste visible à l'utilisateur. Comment devrais-je faire cela?

Source

2012-03-04 JimmyBanks

Pourquoi ne pas utiliser SSL? – 01100110

"Je veux continuer à vérifier que l'agent utilisateur correspond, mais parfois je veux que ce soit correct si l'agent utilisateur ne correspond pas." - Êtes-vous sûr que cette vérification vous est utile? – Amber

La vérification de l'agent utilisateur ajoute absolument * rien * à la sécurité. Si vous corrigez votre code pour ne pas activer le détournement de session, vous pouvez simplement supprimer cette vérification et garantir une meilleure expérience à vos utilisateurs. Si vous ne le faites pas, vous êtes foutu de toute façon (et les pirates de Russion vont pwn votre site :) :) –

L'utilisateur devra se réauthentifier lors du changement de périphérique (plutôt que de provoquer l'erreur), puis vous pouvez utiliser les deux variables $_SESSION['HTTP_USER_AGENT'] authentifiées pour comparer les demandes futures.

Source

2012-03-04 21:18:42 Ing

Pour détourner une session, vous devez connaître son ID. Vous le faites en devinant un ID de session valide ou en l'obtenant auprès du client ou du serveur. Le premier est relativement facile à atténuer: plus il y a d'entropie, mieux c'est. Mais celui-ci ne peut être atténué avec une seule mesure que peut être exposé/obtenu un ID de session sur de multiples façons:

Eavesdropping la communication entre le client et le serveur
eu une fuite lors de la transmission via l'URL (HTTP referrer, les fichiers journaux , etc.)
Cross-site Scripting (XSS)

Certains d'entre eux peuvent être fixés assez facile: l'écoute clandestine peut être évité en utilisant un canal sécurisé (HTTPS par exemple) et les fuites via l'URL peut être évitée par transmettre l'identifiant de session dans un cookie (avec les deux HttpOnly et Sécurisé). La prévention de XSS est la plus difficile car il faut prendre soin de chaque donnée d'entrée générée par l'utilisateur avant de la renvoyer au client. Mais si vous faites cela, vous êtes assez bien protégé contre le détournement de session. Au moins la partie que vous pouvez contrôler en tant qu'attaquant pourrait obtenir le cookie directement à partir du cookie jar du navigateur. Mais c'est hors de votre portée.

Source

2012-03-05 19:26:25 Gumbo

La prémisse derrière la question reflète un malentendu.

L'agent utilisateur n'est pas un moyen efficace pour empêcher le détournement de session. Tout attaquant digne de ce nom peut facilement usurper son User-agent pour qu'il corresponde à celui de l'utilisateur piraté. Cette défense est au mieux la sécurité à travers l'obscurité. La meilleure façon d'empêcher le détournement de session est d'utiliser des pratiques de sécurité appropriées, telles que la gestion sécurisée des sessions, la sécurité SSL, la protection CSRF, la validation des entrées et l'échappement des sorties, la prévention des attaques XSS et autres. OWASP dispose d'excellentes ressources pour sécuriser les applications Web.

Source

2012-03-07 07:37:55

Sécurité de piratage de session

Répondre

Questions connexes