¿Mitigando SSLStrip solo sirviendo un sitio a través de HTTPS?

Sí, sin más medidas, el atacante aún puede realizar SSLStrip. Para que SSLStrip funcione, el atacante solo necesita ser un hombre en el medio, no relacionado con su comportamiento con respecto a HTTP. En una solicitud HTTP entrante, el atacante abriría una conexión HTTPS al servidor real y "eliminaría" el SSL del HTTPS. Por lo tanto, no habría comunicación HTTP entre el atacante y el servidor. Incluso si el comportamiento HTTP del servidor parece irrelevante, es mejor para mitigaciones posteriores desactivar HTTP o crear una redirección permanente.

Cuando solo sirve HTTPS, y está seguro de que desea HTTPS en el futuro, puede mitigar parcialmente utilizando HTTP Strict Transport Security (HSTS) para indicar a los usuarios que solo sirven HTTPS. Esto mitigará el SSLStrip para todos los usuarios desde el momento en que se conecten al menos una vez sin ser atacados.

Puede lograr una mitigación completa para Firefox y Chrome solicitando agregarse a un HSTS whitelist . Firefox y Chrome asumen el uso de HTTPS para los sitios web en esa lista blanca, pero un requisito para estar en esa lista es enviar el encabezado HSTS. Más información sobre la aplicación aquí .

  

Si su sitio solo sirve contenido a través de HTTPS y falla en las solicitudes HTTP, sin redireccionar, ¿sigue siendo vulnerable?

Si el usuario ingresa accidentalmente http://example.com en su barra de direcciones en lugar de https://example.com , sslstrip aún podría interceptar la conexión y engañar al usuario.

Esto también podría ocurrir con los siguientes enlaces maliciosos del usuario: si no notan el candado faltante en la barra de direcciones, podrían ser vulnerables.

HTTP Strict Transport Security puede proteger contra esto si está enviando el encabezado, pero solo si el usuario tiene anteriormente visitó su sitio a través de HTTPS utilizando esa instancia en particular si su navegador, o si ha solicitado que los proveedores del navegador incluyan su sitio en su lista de HSTS precargada. Tenga en cuenta que IE aún no es compatible con HSTS .

Otra cosa a tener en cuenta es que, a menos que marque las cookies como seguras , un atacante puede MITM. otra solicitud HTTP de su víctima e inyecte una solicitud a la versión insegura de su sitio (por ejemplo, agregando <img src="http://example.com/mitm.jpg"/>quelepermitiráaMITMusarcookiesparasusitio.TengaencuentaqueHSTStambiénprotegerácontraesto.

También, si hay vulnerabilidades de XSS en su sitio por el procesamiento de valores de cookies, es posible que un atacante use un Ataque MITM para inyectar un script malicioso aquí a menos que HSTS esté activo. Esto es posible incluso si está configurando cookies seguras: el servidor no puede distinguir qué cookies son seguras cuando las lee (solo obtiene los valores), por lo que no sabe si el atacante ha manipulado algo durante un ataque MITM a través de cualquier conexión HTTP a su servidor.

He cubierto bastante terreno con lo anterior, ampliando lo que pediste, sin embargo, estos son todos los tipos de ataques que se pueden usar aunque no estés escuchando a través de HTTP en el servidor.

  

¿Puede un atacante interceptar su solicitud HTTPS y realizar la solicitud?   "en su nombre", por así decirlo, y ofrezca a su navegador una versión HTTP

Si accede a un sitio HTTPS directamente (desde un marcador, por ejemplo), entonces un ataque MITM SSLStrip sería muy poco probable. La solicitud fallará debido a que el navegador está buscando un protocolo de enlace TLS, o le avisará con un error de certificado si el atacante está utilizando un certificado falso.

Ahora, si está aplicando esto en el lado del servidor, no siempre puede confiar en el servidor para redireccionar HTTP a HTTPS ya que esta redirección podría ser interceptada.

Además, si accede a la página a través de un hipervínculo desde una fuente no cifrada, también será vulnerable a SSLStrip. Sé que su pregunta no se refirió específicamente a estas dos últimas situaciones, pero solo quería mencionarlas para que sean exhaustivas. Hay formas de mitigar estos últimos ataques mediante el uso de HSTS.

Con HSTS , el servidor le dice a un cliente web que use solo HTTPS. Siempre que la primera solicitud al sitio se realice sin modificaciones, todas las visitas posteriores al sitio se verán obligadas a utilizar SSL / TLS. Esto funcionaría para evitar que SSLStrip trabaje en un hipervínculo desde un sitio web no seguro, ya que a pesar de que https:// se cambió a http:// , el navegador sabe que solo debe usar https:// .

Como parte del ataque, se realiza un MITM para todo el tráfico TCP / UDP de las víctimas, siempre que el usuario no use una dirección https explícitamente, podría ser engañado.

Por ejemplo: si una víctima intenta ir a "mail.google.com" y confía en el redireccionamiento automático que Google realiza de http a https (pruébelo usted mismo), y él no verifica la barra de direcciones para activar el bloqueo del teclado. icon / barra verde / lo que sea, un atacante que ya haya hecho el MITM obtendría todo el tráfico de ese sitio en texto claro.

Sin embargo, hay un nuevo encabezado HTTP que puede incluirse en todas las respuestas del servidor que fue diseñado para minimizar las posibilidades de sufrir un ataque de este tipo si el cliente se ha conectado correctamente al HTTPS al menos una vez antes (y usa un navegador web moderno que lo soporta):

Strict-Transport-Security

enlace

Para que un servidor apache incluya este encabezado en todas las respuestas:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

NOTA: si tiene las versiones HTTP y HTTPS de su web, tan pronto como el cliente obtenga ese encabezado de su servidor, no podrá conectarse a la versión HTTP (hasta borra las cookies o usa un navegador diferente o (quizás) usa navegación privada)