Autenticación basada en token bajo http

Navega tus respuestas
2

Estoy haciendo una autenticación basada en token pero enfrentando algunos problemas de seguridad. En el sistema, un usuario iniciará sesión de la siguiente manera:

  1. Escriba el nombre de usuario y la contraseña para iniciar sesión en una página de inicio de sesión https
  2. Si el inicio de sesión se realiza correctamente, el servidor establecerá una 'cookie de autenticación'. De lo contrario, vaya a la página de inicio de sesión nuevamente
  3. La 'cookie de autenticación' en cada solicitud se utilizará para identificar al usuario.

Creo que esto es seguro si la solicitud está en https porque la "cookie de autenticación" no se puede robar fácilmente debido al cifrado de SSL. No quiero que se pueda acceder a todas las páginas de mi sitio web solo a través de https. Sin embargo, si se puede acceder a la página en http, entonces la conexión puede estar sujeta a un ataque "man-in-the-middle". Si se copian los datos en las cookies, entonces se acabó el juego.

¿Qué es una buena práctica de autenticación basada en token de cookie en http? ¿Podría darme la implementación detallada de la buena práctica?

    
pregunta Timespace7 03.12.2013 - 07:34
fuente

2 respuestas

2

Un principio central de OWASP - Seguridad de la capa de transporte insuficiente es que la ID de la sesión nunca es filtrado a través de HTTP. Aunque los sitios de contenido mixto son una mala idea desde el punto de vista de la seguridad, una forma de hacerlo es mediante el uso de la bandera de cookies seguras que le indicará al navegador que no incluya el ID de sesión en las solicitudes que no sean HTTPS.

Si aloja una página HTTP, un atacante podría introducir JavaScript en un MITM para comprometer una sesión autenticada. Las cookies de HTTPOnly evitarían que la carga útil de JavaScript maliciosa lea el valor de la cookie, sin embargo, la carga útil aún podría leer páginas autenticadas utilizando un XmlHttpRequest, obtener tokens de sincronización CSRF y realizar acciones no autorizadas. La solución es usar Escrutinio de transporte HTTP-Strict , que también resuelve el problema de SSLStrip .

HTTPS es extremadamente liviano y verás un aumento en el uso de CPU de aproximadamente 1% -2% cuando uses HTTPS sobre HTTP. No usar HTTPS debido a algunas ilusiones de eficiencia es un error. HTTP / 2.0 puede ser solo HTTPS .

    
respondido por el rook 04.12.2013 - 19:26
fuente
1

Rook hace algunos buenos puntos, solo para expandirse un poco ...

  

no se puede robar fácilmente debido al cifrado de SSL

Solo si establece el indicador de seguridad en la cookie, de lo contrario, un MITM podría inyectar (por ejemplo) un iframe en una página web aparentemente inocua que apunta a su servidor usando http y oler la cookie devuelta.

Otro problema es el de la reparación de la sesión: una vez más, si su navegador cree que está visitando su servidor a través de HTTP y recibe algo que parece una cookie de sesión, su autenticación envuelta en SSL puede reutilizar ese valor para el token de autenticación ( fijación de sesión). Debe asegurarse de que su código genere un nuevo token cuando el usuario intente autenticarse.

Luego existe la posibilidad de un ataque XSS (secuencias de comandos entre sitios) donde un poco de JavaScript puede leer la cookie y retransmitirla a otra parte, por ejemplo. a través de una etiqueta img: la configuración de la marca HTTPonly en la cookie evita esto.

    
respondido por el symcbean 05.12.2013 - 00:09
fuente

Lea otras preguntas en las etiquetas

TLS 1.2 Certificado de servidor y signature_algorithms ¿Este incidente accidental se considera piratería (ilegal)? [cerrado]