1. Principio de ataque
La suplantación de cookies utiliza principalmente la práctica insegura de almacenar información de inicio de sesión del usuario en las cookies en la red actual.
Sabemos que un sistema de usuario general basado en cookies almacenará al menos dos variables en cookies: nombre de usuario y nivel de usuario, donde el nombre de usuario es el nombre de usuario y el nivel de usuario es el nivel de usuario. Cuando nuestro navegador acceda a la página ASP, emitirá algo como
Get /.../file.asp http 1.0
...
Cookies: UserName = User & UserLevel = 1
...
Luego, mientras sepamos el nombre de usuario y los valores de nivel de usuario del administrador (suponiendo administrador y 5 respectivamente), podemos transferirlo
Get /.../file.asp http 1.0
...
Cookies: UserName = Admin & UserLevel = 5
...
para obtener permisos de administrador. Muy simple, ¿verdad? Sin embargo, antes de descubrir la vulnerabilidad, casi todos los sistemas de gestión de usuarios se basaban en las cookies.
2. Almacene de forma segura la información del usuario
Dado que las cookies no son seguras y debemos almacenar información de inicio de sesión del usuario, ¿dónde deben almacenarse?
Notamos que en ASP, además de las cookies, también hay una sesión que puede almacenar información. La sesión se almacena en el servidor y no puede ser cambiado por el cliente a voluntad, por lo que tiene una seguridad extremadamente alta. De esta manera, todos pueden cambiar el código de todas las cookies a sesión.
3. Almacene la información del usuario durante mucho tiempo
La sesión se usa para guardar la información de inicio de sesión del usuario. El método descrito en esta sección se genera.
Hay dos variantes de este método. Proporcionarlo de acuerdo con las cookies. El código para implementar este método es el siguiente:
VBS:
<%
Nombre de usuario Dim, contraseña
nombre de usuario = sesión (nombre de usuario)
Si username = entonces
'No hay información de inicio de sesión de usuario en la sesión
nombre de usuario = request.cookies (nombre de usuario)
contraseña = request.cookies (contraseña)
'Presta atención al nombre de usuario y la contraseña obtenidas en las dos oraciones anteriores para evitar vulnerabilidades de inyección SQL (es decir, filtrar cotizaciones individuales'), omitidas aquí
if username = o contraseña = entonces
'El usuario no ha iniciado sesión
...
demás
'Aquí se supone que se han creado los objetos Conn y RS
rs.open Seleccione Top 1 * de [usuario] donde username = '& username &' y contraseña = '& contraseña &', conn, 1, 3
Si rs.Eof entonces
'La información en las cookies es ilegal
...
demás
'La información en las cookies es legal y se inicia automáticamente
Sesión (nombre de usuario) = nombre de usuario
...
final si
final si
demás
'La información del usuario ya existe en la sesión y se lee directamente
...
final si
%>
JS:
<%
VAR Nombre de usuario, contraseña;
nombre de usuario = session (nombre de usuario) +;
if (username == || username == Undefined) {
// No hay información de usuario en la sesión
nombre de usuario = request.cookies (nombre de usuario) +;
contraseña = request.cookies (contraseña) +;
// Presta atención al nombre de usuario y la contraseña obtenidas en las dos oraciones anteriores para evitar vulnerabilidades de inyección SQL (es decir, filtrar cotizaciones individuales '), omitidas aquí
if (username == || username == Undefined || contraseña == || contraseña == Undefined) {
// El usuario no ha iniciado sesión
...
}
demás {
// Aquí se supone que se han creado los objetos Conn y RS
rs.open (seleccione Top 1 * de [usuario] donde username = ' + username +' y contraseña = ' + contraseña +', conn, 1, 3);
if (rs.eof) {
// La información en las cookies es ilegal
...
}
demás {
// La información en las cookies es legal y se inicia automáticamente
Sesión (nombre de usuario) = nombre de usuario +;
...
}
}
}
demás {
// La información del usuario ya existe en la sesión y se lee directamente
...
}
%>
Sin embargo, este método no es muy seguro para los usuarios, porque el navegador transmitirá cookies cada vez que visita la página, y la cuenta del usuario será robada una vez que otros obtengan las cookies que contienen la contraseña. Para este caso, aparece un segundo método, es decir, agregue un código de verificación de campo a la base de datos de información del usuario. El valor del código se agrega. Al verificar la información del usuario en las cookies, solo se verifican el nombre de usuario y el código de verificación. La ventaja de este método es que incluso si un hacker obtiene las cookies del usuario, solo puede usar este código de verificación temporal para iniciar sesión y no puede obtener la contraseña del usuario. Mientras este usuario inicie sesión con el nombre de usuario y la contraseña nuevamente, el valor del código de verificación cambiará y el hacker no podrá iniciar sesión a través del código de verificación original.
La implementación de este método solo requiere ligeros cambios en el código de método uno mencionado anteriormente. Primero, en su programa de inicio de sesión, debe agregar un párrafo donde la verificación pase para almacenar la información del usuario:
VBS:
<%
Response.cookies (VerifyCode) = int (RND * 2100000000)
%>
JS:
<%
Response.cookies (VerifyCode) = Math.Floor (Math.random () * 2100000000);
%>
Luego, en el código de verificación proporcionado anteriormente, cambie la verificación de cookies (contraseña) a la verificación de cookies (VerifyCode).
4. Conclusión
A través de nuestro análisis y procesamiento, las cookies falsifican la vulnerabilidad se han resuelto por completo, y desde entonces, nuestros programas ASP se han vuelto más seguros.
2007-08-05 20:37 Comienza la escritura
2007-08-05 21:14 La primera edición se completa