Si los sitios redireccionados usan HTTPS

Si el sitio principal utiliza HTTPS, el sitio de redireccionamiento también debería hacerlo.

¿Qué ataques son posibles si no lo hace

Atacante pasivo

• Puede ver todos los elementos vistos por el usuario
• Puede obtener información adicional (qué sitio / chat está vinculado a la página)

Atacante activo

Todo lo que pueda hacer un atacante pasivo, y ...

• ¿Puede MITM la conexión y usar algo como SSLStrip para evitar que la conexión se actualice a HTTPS, lo que permite ver contraseñas, números de tarjetas de crédito, etc.?
• Puede agregar una cookie a la respuesta, lo que les permite rastrear a un usuario
• Puede redirigir el tráfico a un sitio de phishing o un sitio que instala malware.

Cómo evitar el uso de HTTP por completo, para detener herramientas como SSLStrip

• Puede servir un encabezado HSTS, por lo que solo la primera visita (y la primera visita una vez que el encabezado caduque) usará HTTP, por lo que un atacante no puede interceptar el tráfico
• Si desea evitar estas debilidades, puede agregar su sitio a la Lista de precarga de HSTS , lo que evitará las conexiones HTTP.
• Esto tendría que aplicar para ambos sitios, como si el sitio principal fuera HSTS pero la redirección luego el atacante podría redirigir a un sitio que controlan, sin pasar por alto HSTS.

¿Debo usar HTTPS

En general, SÍ

Hay muy pocas ocasiones en las que puede evitar usar HTTPS, todas estas deben aplicarse:

• Firmas tus datos manualmente, y siempre verificas la firma

• No le importa que las personas descubran que su software se está ejecutando en la máquina de alguien

• Usted no maneja ninguna información confidencial, o la información que los usuarios pueden querer mantener en secreto
• No recibirás accidentalmente información confidencial enviada a través de tu sistema.
  • Un ejemplo sería ACARS, no fue para información confidencial, pero los números de las tarjetas de crédito se enviaron sin darse cuenta de los problemas causados. [ forum , paper ]
• No le importa o puede detectar si alguien intercambia los archivos, utilizando otros firmados válidos
• El servicio no implica datos confidenciales (es posible que una página sobre una enfermedad no sea sensible, pero el hecho de que alguien esté buscando información sobre la enfermedad puede ser sensible).

Hay muy pocos casos en los que usar HTTP simple y no HTTPS es una buena idea. Probablemente este no sea uno de ellos.

Considere este escenario: un usuario hace clic en un enlace a http://exmpl.com/foo , con la esperanza de comprar algo nuevo. Un hombre en el medio intercepta la solicitud y responde con una copia de phishing de https://example.com/items/42 en lugar de una redirección a la legítima. El usuario, siendo perezoso como lo son, no comprueba a qué URL se le redirigió; después de todo, sabía que había hecho clic en el enlace correcto. En su lugar, procede a ingresar los detalles de su tarjeta de crédito en el sitio de phishing. Él cree que está comprando Foo en un sitio legítimo, mientras que en realidad está siendo estafado.

Claro, el usuario cometió un error aquí. Pero es un error que no hubiera importado si solo hubieras usado HTTPS.

Cuando el usuario es consciente de la privacidad, es posible que desee minimizar la cantidad de datos que un intruso puede recopilar sobre ellos. Cuando usa HTTPS, entonces toda la solicitud está encriptada. El intruso solo sabe a qué servidor accedió el usuario y (aproximadamente) cuántos datos se intercambiaron.

Cuando exmpl.com no usa HTTPS, el intruso sabe:

• sujeto accedido http://exmpl.com/foo
• El sujeto recibió una redirección de http a https://example.com/items/42
• El sujeto accedió a una URL desconocida (pero ahora fácil de inferir) en el dominio example.com
• El sujeto recibió una respuesta cifrada larga

Cuando usas HTTPS, todo lo que sabe el atacante:

• El sujeto accedió a una URL desconocida en el dominio exmpl.com
• El sujeto recibió una breve respuesta cifrada
• El sujeto accedió a una URL desconocida en el dominio example.com
• El sujeto recibió una respuesta cifrada larga

El atacante no aprende qué redirección usó el usuario y, por lo tanto, no sabe que el usuario visitó items/42 . El atacante tampoco puede estar seguro de que estos dos accesos estaban relacionados.