¿Puede algún hacker robar una cookie del navegador web de un usuario e iniciar sesión con ese nombre en un sitio web?
Al leer esta pregunta, diferentes usuarios obtienen la misma cookie: valor en .ASPXANONYMOUS
y busco una solución, empiezo a pensar, si es posible que alguien realmente robe la cookie de alguna manera, y luego la coloque en su navegador e inicie sesión, digamos como administrador .
¿Sabe cómo la autenticación de formulario puede garantizar que incluso si se roba la cookie, el pirata informático no pueda utilizarla en un inicio de sesión real?
¿Existe algún otro mecanismo de defensa automático alternativo?
¿Es posible robar una cookie y autenticarse como administrador?
Sí, es posible, si la cookie de autenticación de Forms no está cifrada, alguien podría piratear su cookie para otorgarle privilegios elevados o, si no se requiere SSL, copiar la cookie de otra persona. Sin embargo, existen medidas que puede tomar para mitigar estos riesgos:
En el elemento system.web/authentication/forms:
- requerirSSL=verdadero. Esto requiere que la cookie solo se transmita a través de SSL.
- slideExpiration=false. Cuando es verdadero, se puede reactivar un boleto vencido.
- sin cookies = falso. No utilice sesiones sin cookies en un entorno en el que intente imponer la seguridad.
- enableCrossAppRedirects=false. Cuando es falso, no se permite el procesamiento de cookies entre aplicaciones.
- protección = todo. Cifra y codifica la cookie de autenticación de Forms utilizando la clave de máquina especificada en machine.config o web.config. Esta característica impediría que alguien piratee su propia cookie, ya que esta configuración le indica al sistema que genere una firma de la cookie y, en cada solicitud de autenticación, compare la firma con la cookie pasada.
Si así lo desea, puede agregar un poco de protección colocando 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 plano ni su contraseña). Esto requeriría que el atacante robara tanto la cookie de sesión como la cookie de autenticación de formularios.
El escenario en el que se puede robar una cookie ocurre en un entorno inalámbrico público. Si bien usted o yo nunca operaríamos en una configuración de este tipo, puede ser imposible evitar que sus clientes lo hagan.
Si el atacante sabe a qué sitio seguro está conectado, la idea es que se pueda engañar a su navegador para que publique en una versión no segura de la misma URL. En ese momento su cookie está comprometida.
Por eso además httpOnlyCookiesquerrás especificarrequireSSL="true"
<httpCookies httpOnlyCookies="true" requireSSL="true" />
No estoy de acuerdo con el comentario de The Rook, ya que lo encuentro injusto;
@Aristos actualicé mi respuesta. Pero para ser honesto, si utiliza una plataforma de desarrollo de Microsoft, su aplicación será intrínsecamente insegura. – La Torre Hace 22 minutos
La seguridad no ocurre por accidente y no sucede "de inmediato", al menos no en mi experiencia. Nada es seguro hasta que está diseñado para serlo, independientemente de la plataforma o las herramientas.
Mar 24 '2010 01:03
Hay muchas formas de filtrar una identificación de sesión a un atacante. XSS es el ataque más utilizado para secuestrar un ID de sesión y debes probar las vulnerabilidades XSS en tu aplicación. . Un método común para mejorar la solidez 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, probablemente sea una sesión secuestrada. Esta medida de seguridad podría impedir solicitudes legítimas, pero eso es muy poco probable.
No verifique X-Forwarded-For o User-Agent, es trivial para un atacante modificar 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.
