HTML Cookie security

TL; DR: Usa sesiones sobre SSL

Tienes razón, esto es algo malo. La regla general de seguridad en una aplicación, nunca confíe en el usuario , se aplica aquí. El problema es que un desarrollador web perezoso creará que una cookie no cuenta como entrada del usuario.

Esto no podría estar más lejos del caso. Es excepcionalmente fácil hacer modificaciones a cualquier información enviada al servidor desde el cliente, ya sea una entrada directa del usuario o una cookie.

Hay muchos casos de uso de cookies, y desempeñan un papel clave en la seguridad web, pero en este caso, parece que son tan seguros como un elemento de formulario oculto.

Entonces, ¿cómo arreglas esto? Sesiones Una sesión también almacena datos como una cookie, pero a diferencia de sus cookies, es solo una cadena larga. Esto sirve como un método seguro (con una advertencia) para que el servidor identifique a un usuario. Con cada solicitud HTTP, se incluye el ID de sesión. Una vez que el servidor ha asociado una sesión con un cliente, los datos relevantes de la sesión se almacenan en el servidor. El servidor sabe a qué sesión acceder en función de la ID enviada por el cliente.

Un ID de sesión es mejor por varias razones, el servidor controla los datos asociados con la sesión, no el cliente. Por ejemplo, puede almacenar el total de su carrito como una variable de sesión. Si el cliente tuviera acceso directo a esto, podría modificar la cantidad que paga una vez que haya enviado la orden de compra, pero antes de que se cargue su tarjeta.

Podrías almacenar de forma segura el nivel de privilegio de un usuario como una variable de sesión, donde no sería seguro hacerlo también como una cookie regular.

Ahora a las advertencias. Un ID de sesión todavía no es 100% seguro. Si tuviera que iniciar sesión en su sitio a través de una red pública, mi autenticación sería exitosa y usted me proporcionaría un ID de sesión. Ahora, cualquiera que conozca esta identificación puede usarla para enviar solicitudes HTTP como yo. Este es el secuestro de sesión. También existen algunos ataques de tiempo y tales que intentan reducir la entropía que existe en el ID de sesión.

Solo debe permitir que un usuario inicie sesión o se comunique de forma segura con su servidor a través de una conexión SSL / TLS. Esto reducirá en gran medida las posibilidades de un ataque MITM o el secuestro de una sesión. Si también puede restablecer el ID de sesión y requerir que el usuario haya ingresado sus credenciales dentro de un cierto período de tiempo. Por ejemplo, es de esperar que su banco lo obligue a volver a iniciar sesión después de un cierto período de tiempo.

Aquí hay algunos ejemplos de código en PHP para usar sesiones

session_start() // You must include this at the top of every page basically
                // I know, its odd, just go with it

$_SESSION['username'] = $user // How you could save the username to a session

session_unset() // Clear out the session (logout the user). If you really care
                // about security you will overwrite each session var first 

Lo que entiendo de tu pregunta es que obtienes una cookie como user_id=123 y si la cambias a user_id=456 , de repente te registras como otro usuario.

Una forma posible de evitar que los clientes modifiquen las cookies es mediante su firma criptográfica. En el valor de la cookie, incluye tanto el valor real como un hash del valor y alguna clave secreta. Solo las personas que tienen la clave secreta pueden cambiar las cookies.

Esto es difícil de implementar de forma segura por ti mismo, por lo que sería mejor que esta funcionalidad sea compatible con el marco que estás utilizando.