Utilisation d'horodatages pour empêcher le piratage de session?

Question

J'ai cherché des moyens de se prémunir contre le détournement de session, où quelqu'un vole un cookie de session et l'utilise pour accéder au système. Les programmes tels que http://codebutler.com/firesheep facilitent la détection des sessions sur les réseaux sans fil ouverts, et d'autres moyens d'obtenir des sessions incluent des attaques de script inter-site, ou simplement les soulever physiquement de l'ordinateur d'une victime. L'utilisation de SSL pour sécuriser toutes les communications cookie/serveur de session est essentielle pour empêcher le sniff Firesheep, et la définition de HTTPOnly sur le cookie aide à empêcher JavaScript de lire le cookie de session dans les attaques XSS, mais reste vulnérable à AJAX. attaques à base de

Une autre couche doit inclure un jeton de sécurité ou un nonce dans le cookie de session qui est mis à jour à chaque requête. Vous stockez le jeton dans une banque de données côté serveur et dans le cookie, et à chaque requête, vous comparez que le jeton du cookie correspond au jeton dans le magasin de données. Si les jetons ne correspondent pas, cela peut signifier que quelqu'un a volé la session et essaie de l'utiliser afin que vous puissiez ignorer la requête ou invalider la session et demander à l'utilisateur de s'authentifier à nouveau. Cependant, des jetons non concordants peuvent également résulter d'une connexion lente/squameuse. Par exemple, vous pouvez avoir un cas où le serveur reçoit une requête d'un utilisateur réel, met à jour le jeton de session dans le magasin de données du serveur et répond à l'utilisateur avec un cookie de session contenant le jeton mis à jour. Mais l'utilisateur ne reçoit pas la réponse en raison d'une connexion lente/floconneuse, de sorte que l'utilisateur conserve l'ancien jeton de session alors que le nouveau est stocké sur le serveur. Lorsque l'utilisateur réessaie la demande, les jetons ne correspondent pas. L'une des façons de pallier ce problème est que le serveur conserve un historique des derniers jetons et vérifie que ceux-ci correspondent, mais il devient alors le nombre de jetons à conserver, et en fonction de la façon dont ils sont floconneux. la connexion est ou la satisfaction de l'utilisateur, le serveur peut parcourir l'historique avant que la connexion ne revienne et que la session de l'utilisateur soit mise à jour par le navigateur. Une alternative à la conservation d'un historique de jetons consiste à horodater chaque session et à vérifier si les horodateurs sont dans une plage courte et précise, par exemple 30 secondes. Si l'horodatage des cookies de session de l'utilisateur est dans les 30 secondes suivant l'horodatage de la session stockée du serveur, la session est considérée comme authentique.

Exemple pseudocode

def authenticate_request(): 

    if (stored_session.timestamp - session.timestamp > 30 seconds): 
     return False 
    return True 

Cela évite d'avoir à conserver un historique jeton - l'horodatage devient le jeton - mais les attaquants ont une fenêtre de 30 secondes de la possibilité de pirater la session après sa volée. Bien que cela soit vrai, l'alternative token-history n'est pas meilleure car elle offre aux attaquants une fenêtre d'opportunité potentiellement plus longue.

D'autres approches de vérification de l'adresse IP et des changements d'utilisateur-agent ont aussi des problèmes. Les agents utilisateurs sont facilement usurpés, et si un attaquant est capable d'obtenir la session d'un utilisateur, ils peuvent facilement déterminer l'agent utilisateur via le même code XSS ou d'autres moyens.

Si l'utilisateur est sur un périphérique mobile, son adresse IP peut changer fréquemment, ce qui entraînerait de nombreux faux positifs. De plus, l'attaquant pourrait être derrière le même pare-feu de l'entreprise, de sorte que l'adresse IP de l'utilisateur et de l'attaquant est la même que celle du serveur Web externe.

Est-ce que l'utilisation d'un jeton d'horodatage est la bonne approche ou existe-t-il un meilleur moyen? Le tampon de 30 secondes est-il correct?Quelles sont les affaires de bord qui me manquent?

Answer 1

Je ne vois pas comment un horodatage pourrait fonctionner. Il faudrait que l'utilisateur ne passe jamais plus de 30 secondes sur une page avant d'envoyer une autre requête au serveur. Je suis sûr que j'ai passé plus de 30 secondes à lire cette page et à taper cette réponse avant d'appuyer sur "Publier".

Il me semble qu'il y a un problème inhérent que toute donnée que vous envoyez sur la ligne pourrait être interceptée et dupliquée. Encryting un mot de passe ne résout pas le problème, car un pirate peut intercepter la valeur cryptée et ensuite envoyer cette valeur cryptée. Il ne se soucie pas nécessairement de la valeur non cryptée.

Même histoire pour tout jeton envoyé. Le hacker pourrait intercepter le jeton et le dupliquer. La seule idée que j'ai entendu qui semble résoudre le problème est un système de défi-réponse utilisant des clés publiques et privées: A crée une chaîne de caractères aléatoire, la chiffre en utilisant la clé publique de B et l'envoie à B B décrypte cette chaîne à l'aide de sa clé privée et renvoie la valeur déchiffrée avec ses données d'application. A valide ensuite que la valeur déchiffrée correspond à la valeur d'origine. S'il ne valide pas, il rejette les données associées.

Un pirate ne peut pas intercepter le message de A et usurper la réponse s'il ne connaît pas la clé privée de B. Un pirate ne peut pas utiliser une réponse de B interceptée par anticipation parce que la chaîne aléatoire est différente à chaque fois.