Seguridad web: uso de cookies en https

Esto podría lograrse de manera relativamente segura con dos cookies.

Uno tiene el conjunto Secure Flag , y contendrá los detalles de su sesión HTTPS y se utilizará durante el proceso de pago. Proceso al realizar una compra. El Secure Flag garantiza que el navegador solo envíe la cookie a través de conexiones protegidas por SSL / TLS (es decir, use el protocolo HTTPS ).

El otro no tiene este conjunto de indicadores y almacenará los detalles de la sesión HTTP. Los detalles de la sesión almacenados en el lado del servidor pueden ser elementos vistos, o si ha iniciado sesión anteriormente podría vincular su sesión a una cuenta. Esto es lo que se usaría cuando el sitio diga Bienvenido a John cuando regrese sin iniciar sesión.

Para que esto funcione, no debería haber manera de determinar el valor de cookie de sesión segura de la insegura.

La cookie insegura se podría utilizar hasta el momento de ingresar la página de pago o la página de detalles de la cuenta, donde se requiere un inicio de sesión a través de HTTPS donde luego se establece la cookie de sesión segura. Esto evitaría que un ataque MITM obtuviera la cookie, como si un atacante robara lo inseguro lo peor que pueden hacer es modificar el historial de navegación del usuario o agregar / eliminar cosas de la canasta. Si se implementara de esta manera, se supondría que el usuario verificará que los elementos de la cesta copiados en su sesión segura sean los que realmente deseaban ordenar antes de completar el proceso de pago (o que lean su correo electrónico de confirmación y cancelen los elementos más tarde). / p>

De su pregunta no queda claro si su instructor se refiere al envío de cookies de texto sin formato con cuidado utilizando las buenas prácticas como la anterior, o como un mal ejemplo de cómo no hacerlo. Si es el último, muchos sitios web de hecho solo protegen ciertas páginas como el inicio de sesión y las páginas de detalles de la tarjeta con HTTPS, pero luego continúan utilizando la misma autenticación o cookie de sesión en las páginas HTTP, sin darse cuenta de que este valor de cookie se envía en el claro y puede ser leído por un atacante colocado adecuadamente.

En realidad, si el sitio es totalmente HTTPS, entonces todo el sitio está encriptado (encabezados, cookies y todo). Obtenga más información sobre SSL aquí .

Con Amazon, básicamente utilizan una combinación de datos privados seguros (su sesión iniciada) y datos "privados" inseguros (su dirección IP).

Hay dos formas básicas en que un sitio puede "rastrear" lo que describió, de modo que cuando visite Amazon.com por primera vez, visite la página de inicio que no es SSL y puede mostrarle "mágicamente" un montón de elementos sugeridos.

1. Almacena una cookie local (en tu máquina) y la envía a Amazon diciendo "hey, este soy yo". Esta cookie puede estar encriptada o no, y dependiendo de la información que realmente se almacene en la cookie, puede o no ser un riesgo de seguridad.
2. Un sitio también podría hacer esto sin almacenar nada contigo localmente. Hacen esto simplemente vinculando su dirección IP (que se envía como parte de cualquier solicitud HTTP, en texto sin formato) a una IP coincidente que tiene archivada para usted y para volia.

Si bien su ejemplo de Amazon no envía cookies de texto simple seguras y, por lo tanto, no hay mucho riesgo de que lo que usted describió como MiTM , estos tipos de ataques pueden ocurrir, especialmente si ' secure flag 'no está configurado con la cookie.