¿Es posible robar una cookie no segura cuando el servidor web (IIS) solo permite Https?

Por supuesto que es posible ...

Piénsalo de esta manera:

• El indicador secure garantiza que la cookie está bloqueada en HTTPS.
• HTTPS garantiza que la conexión con el servidor (solicitudes + respuestas) esté vinculada al certificado del servidor.
• El certificado del servidor garantiza la identidad real del servidor web.

Ahora, si elimina ese primer paso, la cookie obviamente se puede enviar en una solicitud HTTP ...
Que se puede enviar a un servidor diferente ...
Que se hace pasar por su servidor web.

Hay muchas formas de ataque (por ejemplo, falsificación de DNS) que podrían hacer que te conectes con el servidor incorrecto y, por supuesto, HTTPS (con TLS / SSL) mitiga eso bastante bien.
Incluso si su aplicación real está utilizando HTTPS, no hay garantía de que el servidor falso lo sea, ¿verdad?

Pero no nos detengamos allí, hay un escenario aún más trivial.

Usted dice que su servidor web solo permite HTTPS.
Es decir, solo aceptará solicitudes que sean HTTPS, y rechazará de forma absoluta cualquier solicitud HTTP.
Pero esa solicitud HTTP ya se envió de forma clara.

Si un atacante, o incluso un programador descuidado , puede hacer que se envíe una sola solicitud desde el navegador del usuario a través de HTTP, entonces esa cookie será enviada. A través de HTTP. En el claro. Sin cifrado. (De hecho, he visto esto bastante en la naturaleza, el segundo tipo más que el primero ...)

A menudo, eso es todo lo que se necesita.

Hazte un favor a ti mismo (y a tus usuarios), siempre aplica HTTPS en todos niveles.

El punto central es que aunque el servidor solo acepta HTTPS, el cliente no lo sabe . El usuario humano puede, pero no el cliente de software.

Supongamos la siguiente configuración:

• El servidor solo HTTPS es https://www.bank.com/ .
• Tú eres la víctima.
• El atacante puede escuchar a escondidas (pasivamente) su tráfico.
• El atacante conoce un foro web que lees ocasionalmente.

Luego, el atacante solo tiene que incluir en el foro web el siguiente extracto HTML:

<img src="http://www.bank.com:443/foo.png"/>

Sóloeso.Cuandosunavegadorveaeso,abriráunaconexiónTCPawww.bank.comenelpuerto443;esaconexiónfuncionará,porquewww.bank.comrealmenteesperaconexionesentrantesenelpuerto443.Porsupuesto,elbancoquerrá"hablar SSL", pero a nivel de TCP, la conexión es exitosa (SYN, ACK + SYN, ACK).

Luego, su navegador envía una solicitud HTTP GET a través de la conexión. Esa solicitud incluirá la cookie , a simple vista, ya que el objetivo es www.bank.com y la cookie no se marcó como "segura". Por supuesto, el servidor rechazará el intento porque espera un mensaje SSL ClientHello , no HTTP; sin embargo, eso es demasiado tarde, la cookie ya ha viajado ante los ojos curiosos del atacante.

(Las variantes de los ataques incluyen un atacante más activo con, por ejemplo, la falsificación de DNS para suplantar a un www.bank.com falso, pero el mismo principio sigue siendo el siguiente: ya que el navegador no sabe que el servidor solo hará HTTPS, se alegrará. enviar la cookie a través de HTTP simple.)