https - insurance - obamacare enrollment
¿Es seguro un POST de HTTP a HTTPS? (6)
La transferencia de datos real de su formulario al servidor se cifra cuando se publica a través de HTTPS. Si eso es lo que quiere decir con seguro, entonces sí, es seguro.
Creo que lo que está tratando de resolver en su pregunta es qué pasa con las cosas del lado del cliente que leen el formulario antes de la publicación. Eso es ciertamente posible, HTTPS o no.
Sin embargo, en otra nota, probablemente deberías usar HTTPS para el formulario real. Algunos navegadores advierten a los usuarios ya que sus publicaciones se redirigen a través del límite HTTP / HTTPS. Además, no creo que sus usuarios estén contentos de completar un formulario donde no se muestra un ícono seguro.
Tengo una página HTTP con un formulario. Si configuro la acción en una página HTTPS, ¿es segura la solicitud? ¿El navegador procesa todos los datos antes de enviarlos a la red? ¿O debería usar HTTPS para todo mi sitio?
No. Troy Hunt identifica un simple ataque de hombre en medio que muestra que la publicación de HTTP a HTTPS no es de ninguna manera segura. Con la proliferación de WiFi gratis, este ataque sería muy simple de ejecutar.
http://www.troyhunt.com/2013/05/your-login-form-posts-to-https-but-you.html
Sí, será seguro si la ubicación a la que se publica su formulario es HTTPS.
Sin embargo, los usuarios pueden enloquecer que no haya un ícono de candado en su navegador en la página con el formulario. Es posible que esté mejor desde el punto de vista de la usabilidad si ambas páginas son HTTPS.
Sí. Siempre que la solicitud que debe ser segura sea https, está bien.
Dicho esto, muchos sitios clave, incluido gmail, han dejado de molestarse en cortar pequeñas secciones de su sitio para ser https y solo han hecho su sitio completo https. Es más fácil y seguro, y se pierde poco en el rendimiento.
Si configura la acción en HTTPS, esto será seguro. Antes de que pueda ocurrir algo a través de HTTPS, debe producirse un apretón de manos, y el navegador que envía los datos tendrá que hacer esto cuando ocurra la acción.
No lo hagas
Considere un ataque MITM en el que un atacante sentado en el cable en algún lugar entre el servidor y el cliente modifique el formulario de inicio de sesión antes de que llegue al cliente. El formulario de inicio de sesión ahora incluye un keylogger o apunta la acción POST a una página de phishing en lugar del servidor auténtico. No hay ninguna advertencia o aviso de UI para el usuario final, por lo que siguen adelante y envían el formulario.
Considere un ataque MITM que involucre al atacante que implementa un "Wifi gratuito" en una cafetería (a través de un punto de acceso de un teléfono inteligente o lo que sea). Cuando las personas desprevenidas usan este "Wifi gratuito" para iniciar sesión con un formulario HTTP, a pesar de que realiza una POST a HTTPS, el atacante puede ver las credenciales de texto simple del usuario analizando el tráfico de su red de punto de acceso.
Referencias: