¿Este enfoque de protección de cookies es seguro?

La respuesta corta. Tu mecanismo es demasiado complicado. Existe una solución más simple, mejor y más segura: use SSL en todo el sitio y configure el bit secure en todas sus cookies para que solo se envíen a través de conexiones cifradas (SSL).

Aspecto técnico esencial. Si realmente desea discutir su mecanismo propuesto, podemos hablar de ello, pero creo que las deficiencias técnicas específicas son secundarias al punto más general de que hay un Más simple, mejor manera de hacerlo. Aquí hay algunos detalles:

• Su propuesta asume que la dirección IP del cliente nunca cambiará. Esta no es una buena suposición. Romperá la web para algunos usuarios, especialmente para usuarios móviles.

• Su propuesta cifra la cookie pero no proporciona ninguna protección de integridad ni autenticación de mensajes. Esto es un error. Casi siempre es un error utilizar el cifrado sin autenticación de mensajes.

• Estás inventando tu propio protocolo criptográfico en miniatura. Eso es propenso a errores, y es mejor evitarlo cuando sea posible.

• Su esquema no impide que un atacante reproduzca una cookie antigua. Dependiendo de cómo su aplicación web utilice cookies, esto podría ser un defecto de seguridad benigno o sutil.

Si corrige estos defectos, su propuesta no es del todo irrazonable. Por ejemplo, ASP.NET admite el cifrado y la autenticación de cookies utilizando un MachineKey.

Sin embargo, no te recomiendo que tomes este camino. Si bien es probable que pueda solucionar estos fallos dado un gran esfuerzo, sospecho que la complejidad de inventar cómo hacerlo correctamente es probablemente más de lo que está calificado. Esto es algo complicado, y sería fácil hacer algo mal. (Por ejemplo, presencie las fallas devastadoras en el cifrado de ASP.NET, lo que permitió que los ataques oraculares de relleno para descifrar todo y anular la seguridad de todo el cifrado).

Consejo general. En lugar de intentar hacer algo raro con el cifrado de sus cookies, le sugiero el siguiente consejo:

• En términos generales, sea reacio a almacenar el estado en cookies. En su lugar, guárdelo en la sesión o en la base de datos. De esa manera, todo lo que necesita es una cookie de sesión.

• Use el soporte de administración de sesión integrado en su marco de programación web; no trates de rodar el tuyo (Si intentas rodar el tuyo, puedes terminar fácilmente con vulnerabilidades como la fijación de la sesión).

• Use SSL en todo el sitio. Establezca el indicador secure en todas las cookies.

• Utilice la defensa CSRF para todas las solicitudes POST. Asegúrese de que todas las solicitudes GET no tengan efectos secundarios (las solicitudes de efectos secundarios deben enviarse como POST).

• Lea los materiales de OWASP sobre seguridad de aplicaciones web.

¿Por qué demonios quiere almacenar credenciales (incluso cifradas) en el lado del cliente? La mejor idea es mantener todo en sesiones.

Además, si desea pensar en la seguridad de las cookies, no puede olvidarse de los indicadores como: Secure y HttpOnly .

HttpOnly : este nos protege de cualquier tipo de vulnerabilidad de XSS. Esto significa que no se puede acceder a la cookie con esta bandera a través del script del lado del cliente (por supuesto, solo funciona para los navegadores que admiten esta bandera, en la actualidad, casi todas).

Seguro : esta bandera "obliga" al navegador a usar cookies solo cuando se establece una conexión segura / encriptada.

La solución general que utilizo para proteger las cookies y las páginas son

• Use HTTPS para inicios de sesión y páginas privadas como PMs (o tenga el https del sitio completo)
• Envíe de vuelta una cookie segura y solo HTTP con un token de "inicio de sesión" o "auth" (verificamos si coincide con el usuario). Este token se usa para páginas privadas como PMs.
• Envíe de nuevo otro token de inicio de sesión / autenticación que sea http solo pero no seguro para que pueda usarse para páginas que no sean https (esto es opcional. Pero si le gusta mostrar el nombre de usuario, los mensajes o permitir que un usuario publique comentarios públicos, tiene) para ser una forma de autentificarlos, por lo que puede ser necesario si desea que se encuentre en páginas que no sean https)
• Use una cookie WantHttp, de modo que si un usuario hace clic en un enlace a una versión no http del sitio, se lo redirigirá automáticamente a la versión https
• Tenga un token CSRF que usan todos los formularios en cada página. Seleccionado al azar pero no igual en todos los usuarios (no constante)
• Tener ese mismo token CSRF como una cookie solo HTTP. Cada vez que se realiza una solicitud POST, verifique el formulario y la cookie para ver si coinciden. No se requiere búsqueda en la base de datos (solo observe los valores de las cookies y los formularios). Si no coinciden, un atacante está intentando enviar automáticamente una solicitud en nombre de los usuarios. Los atacantes no pueden saber qué es el token de los usuarios, ya que no pueden solicitar páginas ni leerlas. No pueden ver la cookie httponly con js. Pueden solicitar un http página mientras busca paquetes y lea sus cookies. En ese caso, siempre use https en cada página con un formulario y marque la cookie de token como segura.