asp.net - ¿Puede algún hacker robar la cookie de un usuario e iniciar sesión con ese nombre en un sitio web?
security cookies (6)
¿Es posible robar una cookie y autenticarse como administrador?
Sí, es posible, si la cookie de autenticación de formularios no está encriptada, alguien podría hackear sus cookies para otorgarles privilegios elevados o si no se requiere SSL, copie la cookie de otra persona. Sin embargo, hay pasos que puede seguir para mitigar estos riesgos:
En el elemento system.web / authentication / forms:
- requireSSL = verdadero Esto requiere que la cookie solo se transmita a través de SSL
- slidingExpiration = falso. Cuando es verdadero, un ticket expirado puede ser reactivado.
- cookieless = falso No use sesiones sin cookies en un entorno en el que intente imponer la seguridad.
- enableCrossAppRedirects = falso. Cuando es falso, no se permite el procesamiento de cookies en todas las aplicaciones.
- protección = todo. Encripta y mezcla la cookie de autenticación de formularios con la clave de máquina especificada en machine.config o web.config. Esta característica evitará que alguien piratee su propia cookie, ya que esta configuración le dice al sistema que genere una firma de la cookie y en cada solicitud de autenticación, compare la firma con la cookie pasada.
Si lo desea, podría agregar un poco de protección al poner algún tipo de información de autenticación en la sesión, como un hash del nombre de usuario del usuario (nunca el nombre de usuario en texto sin formato ni su contraseña). Esto requeriría que el atacante robe tanto la cookie de sesión como la cookie de autenticación de formularios.
Leyendo esta pregunta
diferentes usuarios obtienen el mismo valor de cookie en aspxanonymous
y buscar una solución, empiezo a pensar, si es posible que alguien robe realmente la cookie de alguna manera, y luego la coloco en su navegador y me registro como administrador .
¿Sabes cómo la autenticación de formularios puede garantizar que incluso si se roba la cookie, el pirata informático no tiene un inicio de sesión real al usarla?
¿O conoces algún otro mecanismo de defensa automático?
Gracias por adelantado.
El escenario donde se puede robar una cookie ocurre en un entorno inalámbrico público. Mientras que usted o yo nunca operaríamos en dicha configuración, puede ser imposible evitar que sus clientes lo hagan.
Si el atacante sabe a qué sitio seguro estás conectado, la idea es engañar a tu navegador para que publique en una versión no segura de la misma URL. En ese punto su cookie está comprometida.
Es por eso que además de httpOnlyCookies , querrás especificar requireSSL="true"
<httpCookies httpOnlyCookies="true" requireSSL="true" />
No estoy de acuerdo con el comentario de The Rook, porque me parece injusto;
@Aristos actualicé mi respuesta. Pero, para ser sincero, si utiliza una plataforma de desarrollo de Microsoft, su aplicación será intrínsecamente insegura. - The Rook hace 22 minutos
La seguridad no ocurre por accidente y no ocurre "directamente de la caja", al menos no en mi experiencia. Nada es seguro hasta que esté diseñado para serlo, independientemente de la plataforma o las herramientas.
En muchos casos, las cookies utilizadas para la autenticación se combinan con una sesión en el servidor, por lo que no solo es posible tomar una cookie y estar ''conectado'', sin embargo, es posible que desee obtener una lectura acerca de las solicitudes cruzadas de falsificaciones. , lo que sí permite un mecanismo para que esta cookie se use maliciosamente:
Estoy trabajando en esto, y se me ocurre una idea, que no estoy seguro de si es 100% segura, pero es una idea.
Mi idea es que cada usuario debe pasar desde la página de inicio de sesión.
Si alguien robó la cookie, no pasa la página de inicio de sesión, sino que va directamente al interior de las páginas restantes. No puede pasar la página de inicio de sesión, porque no conocía la contraseña, así que si pasa, falla de todos modos.
Así que coloco un valor de sesión adicional, que el usuario ha aprobado con éxito la página de inicio de sesión. Ahora, dentro de cada página crítica, verifico el valor de la sesión extra y si la encuentro nula, inicio sesión y vuelvo a pedir la contraseña.
Ahora no lo sé, tal vez todo lo que haya hecho todo listo por microsoft, necesite verificarlo más.
Para verificar esta idea, uso esta función que hace que un usuario inicie sesión directamente.
FormsAuthentication.SetAuthCookie("UserName", false);
Mi segunda seguridad, que tengo todo preparado y uso, es que verifico diferentes ips y / o cookies diferentes del mismo usuario conectado. He pensado mucho en eso, muchos controles (si está detrás del proxy, si es de diferentes países, qué es lo que se busca, cuántas veces lo he visto, etc.), pero esta es la idea general.
Este video muestra exactamente lo que intento evitar. Al usar el truco que describí aquí, no puedes simplemente establecer la cookie de inicio de sesión solamente.
Solo compartiendo mis ideas ...
Hay muchas maneras de filtrar una identificación de sesión a un atacante. XSS es el ataque más comúnmente utilizado para secuestrar una ID de sesión y debe probar las vulnerabilidades XSS en su aplicación. . Un método común para mejorar la fuerza de una sesión es verificar la dirección IP. Cuando el usuario inicia sesión, registre la dirección IP. Verifique la dirección IP para cada solicitud, si la IP cambia entonces probablemente sea una sesión secuestrada. Esta medida de seguridad podría evitar solicitudes legítimas, pero eso es muy poco probable.
No verifique X-Forwarded-For o User-Agent, es trivial que un atacante modifique estos valores.
También recomiendo habilitar httpOnlyCookies en su archivo web.config:
<httpCookies httpOnlyCookies="true"/>
Esto hace que sea más difícil para un atacante secuestrar una sesión con javascript, pero aún es posible.
No conozco los detalles de la cookie en cuestión, pero en general es una mala práctica almacenar tanto el nombre de usuario como la contraseña en una cookie de usuario. Generalmente, solo desea almacenar el nombre de usuario en la cookie junto con otra información no confidencial. De esta forma, se solicita al usuario que proporcione su contraseña solo al iniciar sesión.