Considérant que le développement ASP peut utiliser deux langages : vbs et js, les codes de programme dans les deux langues sont fournis ici (version bilingue ? YY medium...) Une dernière phrase verbeuse, la machine avec laquelle j'ai tapé cet article n'a pas de Environnement ASP, donc le code fourni n'a pas été testé, et je m'en excuse. Si vous rencontrez des problèmes dans le code, n'hésitez pas à commenter~J'ai la peau épaisse~
1. Principe d'attaque
L'usurpation de cookies exploite principalement la pratique dangereuse consistant à stocker les informations de connexion des utilisateurs dans des cookies par certains systèmes de gestion des utilisateurs sur le réseau actuel. Sa méthode d'attaque est relativement difficile par rapport aux vulnérabilités telles que les vulnérabilités d'injection SQL, mais elle reste très stupide.
Nous savons qu'un système utilisateur général basé sur les cookies stockera au moins deux variables dans les cookies : le nom d'utilisateur et le niveau d'utilisateur, où nom d'utilisateur est le nom d'utilisateur et niveau d'utilisateur est le niveau de l'utilisateur. Lorsque notre navigateur accède à une page ASP, il enverra quelque chose comme
OBTENIR /.../file.asp HTTP 1.0
...
Cookies : username=user&userlevel=1
...
paquet, alors tant que nous connaissons le nom d'utilisateur et les valeurs de niveau d'utilisateur de l'administrateur (supposés être admin et 5 respectivement), nous pouvons transmettre
OBTENIR /.../file.asp HTTP 1.0
...
Cookies : nom d'utilisateur=admin&userlevel=5
...
pour obtenir les droits d'administrateur. Très simple n'est-ce pas ? Cependant, avant que cette vulnérabilité ne soit découverte, presque tous les systèmes de gestion des utilisateurs reposaient sur des cookies.
2. Stockez les informations utilisateur en toute sécurité
Étant donné que les cookies ne sont pas sécurisés et que nous devons stocker les informations de connexion des utilisateurs, où doivent-elles être stockées ?
Nous avons remarqué que dans ASP, en plus des cookies, il existe également une session qui peut stocker des informations. La session est stockée sur le serveur et ne peut pas être modifiée de manière fortuite par le client, elle présente donc un niveau de sécurité extrêmement élevé. De cette façon, vous pouvez remplacer tous les codes Cookies par Session.
3. Stockez les informations utilisateur pendant une longue période
Utiliser la session pour enregistrer les informations de connexion de l'utilisateur, bien que cela élimine le problème de la tromperie des cookies, la session ne peut pas être stockée pendant une longue période (la session par défaut d'IIS expire 20 minutes après que l'utilisateur cesse de répondre), donc la méthode de stockage hybride Cookies + Session est décrite dans cette section est produit.
Il existe deux variantes de cette méthode. La première consiste à stocker le nom d'utilisateur et le mot de passe dans des cookies. Lorsque l'utilisateur visite une page, la session est lue en premier. S'il y a du contenu, la session prévaut. être lu et les informations fournies dans les cookies seront utilisées. Connectez-vous de manière opaque avec votre nom d'utilisateur et votre mot de passe pour déterminer si le contenu des cookies est légal. S'il est légal, il sera stocké dans la session. Le code pour implémenter cette méthode est le suivant :
vb :
Copiez le code comme suit :
<%
Dim nom d'utilisateur, mot de passe
nom d'utilisateur = Session (nom d'utilisateur)
si nom d'utilisateur = alors
' Il n'y a aucune information de connexion utilisateur dans la session
nom d'utilisateur = Request.Cookies (nom d'utilisateur)
mot de passe = Request.Cookies (mot de passe)
' Notez que le nom d'utilisateur et le mot de passe obtenus dans les deux phrases ci-dessus doivent être protégés des vulnérabilités d'injection SQL (c'est-à-dire que les guillemets simples sont filtrés »), qui sont omis ici.
si nom d'utilisateur = ou mot de passe = alors
'L'utilisateur n'est pas connecté
...
autre
' Cela suppose que les objets conn et rs ont été créés
rs.Open SELECT TOP 1 * FROM [user] WHERE username=' & username & ' AND password=' & password & ', conn, 1, 3
si rs.eof alors
'Les informations contenues dans les cookies sont illégales
...
autre
'Les informations contenues dans les cookies sont légales, connectez-vous automatiquement
Session (nom d'utilisateur) = nom d'utilisateur
...
finir si
finir si
autre
'Les informations utilisateur existent déjà dans la session, lisez-les directement
...
finir si
%>
js :
Copiez le code comme suit :
<%
var nom d'utilisateur, mot de passe ;
nom d'utilisateur = Session (nom d'utilisateur) + ;
if (nom d'utilisateur == || nom d'utilisateur == non défini) {
// Il n'y a aucune information utilisateur dans la session
nom d'utilisateur = Request.Cookies (nom d'utilisateur) + ;
mot de passe = Request.Cookies(mot de passe) + ;
// Notez que le nom d'utilisateur et le mot de passe obtenus dans les deux phrases ci-dessus doivent empêcher les vulnérabilités d'injection SQL (c'est-à-dire filtrer les guillemets simples '), qui sont omis ici.
if (nom d'utilisateur == || nom d'utilisateur == non défini || mot de passe == || mot de passe == non défini) {
//L'utilisateur n'est pas connecté
...
}
autre {
// Cela suppose que les objets conn et rs ont été créés
rs.Open(SELECT TOP 1 * FROM [user] WHERE username=' + username + ' AND password=' + password + ', conn, 1, 3);
si (rs.eof) {
//Les informations contenues dans les cookies sont illégales
...
}
autre {
//Les informations contenues dans les Cookies sont légales, connectez-vous automatiquement
Session(nom d'utilisateur) = nom d'utilisateur + ;
...
}
}
}
autre {
// Les informations utilisateur existent déjà dans la session, lisez-les directement
...
}
%>
Cependant, cette méthode n'est pas très sûre pour les utilisateurs car le navigateur transmettra des cookies à chaque fois qu'ils visiteront la page, et une fois que les cookies contenant les mots de passe seront obtenus par d'autres, le compte de l'utilisateur sera volé. Pour cette situation, il existe une deuxième méthode, qui consiste à ajouter un champ de code de vérification dans la base de données d'informations utilisateur. Lorsque l'utilisateur se connecte, une valeur de vérification entière longue est générée de manière aléatoire et stockée dans le champ du code de vérification, ainsi que le nom d'utilisateur et ce code de vérification. la valeur est ajoutée. Stockez les cookies au lieu du mot de passe. Lors de la vérification des informations 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 informatique, celui-ci ne peut utiliser que le code de vérification généré temporairement pour se connecter, mais ne peut pas obtenir le mot de passe de l'utilisateur. Tant que cet utilisateur se connecte à nouveau en utilisant le nom d'utilisateur et le mot de passe, la valeur du code de vérification changera et les pirates ne pourront pas se connecter via le code de vérification d'origine.
La mise en œuvre de cette méthode ne nécessite que de légères modifications du code de la méthode 1 ci-dessus. Tout d'abord, dans votre programme de connexion, vous devez ajouter un paragraphe où les informations utilisateur sont stockées après vérification :
vb :
Copiez le code comme suit :
<%
Réponse.Cookies (code de vérification) = int (rnd * 2100000000)
%>
js :
Copiez le code comme suit :
<%
Réponse.Cookies(verifycode) = Math.floor(Math.random() * 2100000000);
%>
Ensuite, remplacez la vérification des cookies (mot de passe) par la vérification des cookies (verifycode) dans le code de vérification fourni ci-dessus.
4. Conclusion
Grâce à notre analyse et à notre traitement, la vulnérabilité d'usurpation d'identité des cookies a été complètement résolue. Depuis lors, notre programme ASP est devenu plus sécurisé.