¿Qué es el secuestro de sesiones y cómo puede detenerlo?

Esta historia es para principiantes y para cualquier persona que tenga un conocimiento básico sobre las cookies (cookies de sesión), pero que no esté seguro de cómo protegerlas correctamente. No es necesario ser un experto en seguridad para hacer eso. Solo tienes que entender el proceso y luego lo sabrás.

Si no tiene idea sobre las cookies o cómo funcionan, lea este artículo sobre las cookies HTTP.

¡Hagámoslo! Tienes una aplicación web increíble que ofrece un excelente servicio a los clientes. Eso significa que tendrá un mecanismo de autenticación para que el usuario acceda a su aplicación. Sabes lo importante que es la seguridad. Implementó todo tipo de medidas de seguridad durante la autenticación. ¡Excelente!

Tras la autenticación exitosa, debe crear una sesión para ese usuario. Esto significa que en realidad está creando una cookie y devolviéndola al navegador. Por ejemplo, en una aplicación web Java, de forma predeterminada, se llama JSESSIONID. Se parece a esto:

Al utilizar esta cookie, solo su servidor web puede identificar quién es el usuario y proporcionará el contenido correspondiente. Y esta galleta se ve genial. No hay información confidencial en la cookie, solo la identificación aleatoria (no adivinable). ¡Entonces el usuario está seguro! …¿derecho?

Bueno, no exactamente, echemos un vistazo más de cerca.

Hay dos propiedades en esta cookie: HttpOnly (HTTP) y Secure. Sus valores están en blanco, lo que significa que no están habilitados para esta cookie . Ahí es donde se llega al punto en que ya no es seguro.

Aquí es donde entra en juego el secuestro de sesión.

El secuestro de sesiones , a veces también conocido como secuestro de cookies , es la explotación de una sesión de computadora válida , a veces también llamada clave de sesión , para obtener acceso no autorizado a información o servicios en un sistema informático. - Wikipedia

Entonces, es el acto de robar la identificación de sesión de un cliente, mediante el cual pueden acceder a su aplicación web como si fueran ese cliente.

es posible? ¿Cómo obtienen ese ID de sesión que está en el navegador del usuario?

Si es posible. Las dos propiedades de las cookies (o banderas) que vimos anteriormente ( HttpOnly y Secure ) son la razón de esto.

Bandera HttpOnly

HttpOnlylas cookies son inaccesibles a la Document.cookieAPI de JavaScript ; solo se envían al servidor. Por ejemplo, las cookies que persisten en las sesiones del lado del servidor no necesitan estar disponibles para JavaScript y se HttpOnlydebe establecer la marca.

Entonces, en términos simples, si no configura la marca httpOnly, entonces su cookie se puede leer desde el código JavaScript del front-end.

Abra cualquier página web cuya cookie no tenga configurado el indicador httpOnly. Luego, abra Chrome Dev Console y luego toque la pestaña Consola (Cmd + Shift + J o Ctrl + Shift + J). Escriba document.cookiee ingrese, y verá algo como esto:

Como puede ver, obtiene toda la información de las cookies. Un atacante de JavaScript puede simplemente publicar esto en su propio servidor para su uso posterior.

Quizás se pregunte cómo pueden escribir este código en su aplicación. Es posible de varias formas.

Una forma es inyectar alguna biblioteca JS de terceros que no sea de confianza, como registros, utilidades auxiliares, etc. Lea este artículo Estoy recolectando números de tarjetas de crédito y contraseñas de su sitio. He aquí cómo .

Otra forma es mediante el uso de un ataque de secuencia de comandos entre sitios . No vamos a entrar en detalles, pero recuerde que se puede hacer.

? Entonces, como lo arreglamos?

La cookie de sesión ni siquiera necesita ser accesible por el cliente JavaScript. Solo es necesario para el servidor. Deberíamos hacerlo accesible solo para el servidor. Puede hacerlo agregando una palabra ( httpOnly ) en su encabezado de respuesta http set_cookie . Me gusta esto:

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly

Al agregar la marca httpOnly , le indica al navegador que el código JavaScript no debe leer esta cookie. El navegador se encargará del resto. Así es como se ve después de agregar la bandera httpOnly:

Observe la marca de verificación en la propiedad HTTP. Eso indica que httpOnly está habilitado.

Aquí puede ver que document.cookie no devuelve nuestra cookie de sesión. Lo que significa que ningún JS puede leerlo, incluidos los scripts externos.

Eso es todo, ¡uno menos que uno!

Bandera segura

La bandera segura indica al navegador que la cookie solo debe devolverse a la aplicación a través de conexiones cifradas, es decir, una conexión HTTPS.

Por lo tanto, cuando se envía una cookie al navegador con la bandera segura, y cuando realiza una solicitud a la aplicación mediante HTTP, el navegador no adjuntará esta cookie en la solicitud. Lo adjuntará solo en una solicitud HTTPS. La solicitud HTTPS se cifrará para que las cookies se envíen de forma segura a través de la red a su aplicación.

¿Cómo puede alguien leer la cookie en la solicitud HTTP?

Esto se puede lograr cuando alguien (llamado ataque "Man in the Middle" ) está monitoreando todo el tráfico en la red de clientes. Pueden ver los datos de texto sin cifrar si la solicitud está en HTTP.

Cuando se envía a través de HTTPS , todos los datos se cifrarán desde el navegador y se enviarán a la red. El atacante no podrá obtener los datos sin procesar que estaba enviando. El atacante tampoco podrá descifrar el contenido. Es por eso que enviar datos a través de SSL es seguro.

? Entonces, como lo arreglamos?

Al igual que la bandera httpOnly, solo necesita agregar la bandera segura en su encabezado de respuesta HTTP set_cookie . Me gusta esto:

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly; Secure

En Java se puede hacer de varias formas. Si está utilizando Servlet 3.0 o superior, puede configurar estos ajustes en web.xml de esta manera:

  true true  

Si su entorno no lo admite, puede agregarlo manualmente. Por ejemplo, usando Servlets puede hacer esto:

Finalmente, así es como se ve cuando se establecen ambas banderas,

Conclusión

Por lo tanto, cuando se trata de cookies de sesión o cualquier otra cookie importante, asegúrese de agregar estas dos banderas.

¡Gracias por leer, Happy Securing!