1. Principe d'attaque
Les cookies usurpés utilisent principalement la pratique dangereuse de stocker les informations de connexion des utilisateurs dans les cookies sur le réseau actuel.
Nous savons qu'un système d'utilisateur basé sur des cookies General stockera au moins deux variables dans les cookies: le nom d'utilisateur et UserRevel, où le nom d'utilisateur est le nom d'utilisateur et UserLevel est le niveau de l'utilisateur. Lorsque notre navigateur accède à la page ASP, il émettra quelque chose comme
Get /.../file.asp http 1.0
...
Cookies: nom d'utilisateur = utilisateur et userLevel = 1
...
Ensuite, tant que nous connaissons le nom d'utilisateur de l'administrateur et les valeurs UserLevel (en supposant respectivement l'administrateur et 5), nous pouvons le transférer
Get /.../file.asp http 1.0
...
Cookies: nom d'utilisateur = admin & userlevel = 5
...
pour obtenir des autorisations administratrices. Très simple, non? Cependant, avant la découverte de la vulnérabilité, presque tous les systèmes de gestion des utilisateurs se sont appuyés sur des cookies.
2. Stocker en toute sécurité les informations utilisateur
Étant donné que les cookies sont dangereux et que nous devons stocker les informations de connexion des utilisateurs, où devraient-ils être stockés?
Nous avons remarqué que dans ASP, en plus des cookies, il y a aussi une session qui peut stocker des informations. La session est stockée sur le serveur et ne peut pas être modifiée par le client à volonté, il a donc une sécurité extrêmement élevée. De cette façon, tout le monde peut changer le code de tous les cookies en session.
3. Stockez les informations des utilisateurs pendant longtemps
La session est utilisée pour enregistrer les informations de connexion de l'utilisateur. La méthode décrite dans cette section est générée.
Il y a deux variantes de cette méthode. Fournissez-le en fonction des cookies. Le code pour implémenter cette méthode est le suivant:
VBS:
<%
Nom d'utilisateur DIM, mot de passe
nom d'utilisateur = session (nom d'utilisateur)
Si le nom d'utilisateur = alors
'Il n'y a pas d'informations de connexion utilisateur dans la session
username = request.cookies (nom d'utilisateur)
mot de passe = request.cookies (mot de passe)
`` Faites attention au nom d'utilisateur et au mot de passe obtenu dans les deux phrases ci-dessus pour empêcher les vulnérabilités d'injection SQL (c'est-à-dire filtrer les devis '), omis ici
Si username = ou mot de passe = alors
'L'utilisateur n'est pas connecté
...
autre
'Ici, on suppose que les objets Conn et RS ont été créés
Rs.Open Sélectionnez Top 1 * FROM [USER] WHERE USERNAME = '& USERNAME &' AND PASSOW = '& Password &', Conn, 1, 3
Si Rs.Eof alors
'Les informations dans les cookies sont illégales
...
autre
`` Les informations dans les cookies sont légales et automatiquement connectées
Session (nom d'utilisateur) = nom d'utilisateur
...
terminer si
terminer si
autre
«Les informations utilisateur existent déjà dans la session et sont lues directement
...
terminer si
%>
JS:
<%
Nom d'utilisateur var, mot de passe;
username = session (nom d'utilisateur) +;
if (username == || username == Undefined) {
// il n'y a pas d'informations utilisateur dans la session
username = request.cookies (nom d'utilisateur) +;
mot de passe = request.cookies (mot de passe) +;
// prête attention au nom d'utilisateur et au mot de passe obtenu dans les deux phrases ci-dessus pour empêcher les vulnérabilités d'injection SQL (c'est-à-dire filtrer les devis simples), omis ici
if (username == || username == Undefined || mot de passe == || mot de passe == Undefined) {
// l'utilisateur n'est pas connecté
...
}
autre {
// Ici, on suppose que les objets Conn et RS ont été créés
Rs.open (Sélectionnez Top 1 * From [User] Where Username = '+ Username +' et Password = '+ Password +', Conn, 1, 3);
if (Rs.Eof) {
// Les informations dans les cookies sont illégales
...
}
autre {
// Les informations dans les cookies sont légales et automatiquement connectées
Session (nom d'utilisateur) = nom d'utilisateur +;
...
}
}
}
autre {
// Les informations utilisateur existent déjà dans la session et sont lues directement
...
}
%>
Cependant, cette méthode n'est pas très sûre pour les utilisateurs, car le navigateur transmettra des cookies à chaque fois qu'il visite la page, et le compte de l'utilisateur sera volé une fois que les cookies contenant le mot de passe sont obtenus par d'autres. Pour ce cas, une deuxième méthode apparaît, c'est-à-dire un code de vérification de champ à la base de données d'informations utilisateur. La valeur du code est ajoutée. Lors de la vérification des informations de l'utilisateur dans les cookies, seuls le nom d'utilisateur et le code de vérification sont vérifiés. L'avantage de cette méthode est que même si les cookies de l'utilisateur sont obtenus par un pirate, il ne peut utiliser ce code de vérification temporaire pour se connecter et ne peut pas obtenir le mot de passe de l'utilisateur. Tant que cet utilisateur se connecte à nouveau avec le nom d'utilisateur et le mot de passe, la valeur de code de vérification changera et le pirate ne pourra pas se connecter via le code de vérification d'origine.
L'implémentation de cette méthode ne nécessite que de légères modifications au code de la méthode un mentionné ci-dessus. Tout d'abord, dans votre programme de connexion, vous devez ajouter un paragraphe où la vérification passe pour stocker les informations de l'utilisateur:
VBS:
<%
Réponse.cookies (VerifyCode) = int (RND * 2100000000)
%>
JS:
<%
Réponse.cookies (VerifyCode) = math.floor (math.random () * 2100000000);
%>
Ensuite, dans le code de vérification fourni ci-dessus, modifiez la vérification des cookies (mot de passe) en vérification des cookies (VerifyCode).
4. Conclusion
Grâce à notre analyse et à notre traitement, la vulnérabilité de l'usurpation des cookies a été complètement résolue, et depuis lors, nos programmes ASP sont devenus plus sécurisés.
2007-08-05 20:37 L'écriture commence
2007-08-05 21:14 La première édition est terminée