2010-10-20 23 views
24

Tengo una página HTTP con un formulario. Si configuro la acción en una página HTTPS, ¿está segura la solicitud? ¿El navegador procesa todos los datos antes de enviarlos a la red? ¿O debería usar HTTPS para todo mi sitio?¿Es seguro un POST de HTTP a HTTPS?

+0

posible duplicado de [¿Es seguro para presentar de una forma de HTTP a HTTPS?] (Http: //stackoverflow.com/questions/274274/is-it-secure-to-submit-from-a-http-form-to-https) – RobEarl

+0

Su respuesta aceptada generalmente se considera asesoramiento desactualizado. Por favor vea mi respuesta: http://stackoverflow.com/a/22625230/2179408 –

Respuesta

10

No. Troy Hunt identifica un simple man-in-the-middle attack que muestra que la publicación de HTTP a HTTPS no es de ninguna manera segura. Con la proliferación de WiFi gratuito, este ataque sería muy simple de ejecutar.

http://www.troyhunt.com/2013/05/your-login-form-posts-to-https-but-you.html

+0

publicar en sitios HTTPS completos tampoco, creo. –

+0

Lo sentimos, @ Kstro21, no estoy seguro de lo que quiere decir. ¿Quiere decir que este exploit todavía podría ocurrir de HTTPS a HTTPS? La primera página se cifra entre el servidor y el cliente, sin que el atacante tenga la oportunidad de inyectar el script. –

+0

Por lo tanto, la publicación desde HTTPS a HTTPS nunca se verá afectada por un ataque de hombre en el medio, sin importar el exploit utilizado. Esto es lo que querías decir? –

23

Sí, será seguro si la ubicación en la que se está publicando el formulario es HTTPS.

Los usuarios, sin embargo, pueden enloquecer de 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, ya que ambas páginas deben ser HTTPS.

+0

Entonces ... ¿esta respuesta está mal? La respuesta aceptada aquí, y las respuestas + votadas más votadas [aquí] (https://stackoverflow.com/a/274280/1175496) sugieren que el formulario podría estar sujeto a un ataque MITM. –

+1

@TheRedPea Mi respuesta es la técnica: una POST HTTP a HTTPS es realmente segura. La respuesta aceptada es correcta (y aceptada como tal) por razones más prácticas, siendo que incluso si el HTTP a HTTPS es seguro, el formulario en el sitio HTTP podría ser trivialmente MITMed para publicar en algún lugar * inseguro *. – ceejayoz

2

Si establece la acción en HTTPS, esto será seguro. Antes de que algo pueda suceder 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.

7

Sí. Siempre que la solicitud que necesita ser segura sea https, está bien.

Dicho esto, muchos sitios clave, incluido gmail, han dejado de molestar a la talla de pequeñas secciones de su sitio para ser https y acaba de hacer todo su sitio https. Es más fácil y seguro, y se pierde poco en cuanto a rendimiento.

+0

Y chico, ¿es más fácil? Si se realiza correctamente, los ID de sesión y los que realmente deberían regenerarse cada vez que un usuario cambia entre una conexión HTTP/HTTPS. (Esto es para ayudar a minimizar el riesgo de secuestro de sesión. Una vez que la ID de sesión ha sido aprobada en texto claro, debe considerarse comprometida, desde una perspectiva de seguridad). Habiendo trabajado en dos o tres aplicaciones que regeneraban estas identificaciones constantemente, puede decirte por experiencia que es un gran dolor en el culo. Solo bloquear en HTTPS y comprometerse con él es la única manera de hacerlo, en mi opinión. –

3

La transferencia de datos real de su formulario al servidor se cifra al publicar a través de HTTPS. Si eso es lo que quiere decir con seguridad, entonces sí, es seguro.

Creo que a lo que se enfrenta en su pregunta es, ¿qué pasa con las cosas del lado del cliente leyendo el formulario antes de publicarlo? Eso es ciertamente posible, HTTPS o no.

Sin embargo, en otra nota, probablemente deba usar HTTPS para el formulario real. Algunos navegadores advierten a los usuarios 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 muestre ningún icono seguro.

2

¡No lo haga!

Considere un ataque MITM donde un atacante sentado en el cable en algún lugar entre el servidor y el cliente modifica el formulario de inicio de sesión antes de que llegue al cliente. El formulario de inicio de sesión ahora incluye un registrador de teclas o apunta la acción POST a una página de phishing en lugar de a un servidor auténtico. No hay ninguna señal de advertencia o UI para el usuario final, por lo que seguir adelante y enviar el formulario.

Considere un ataque MITM que involucre al atacante desplegando un "Wifi gratis" en una cafetería (a través de un punto de acceso para smartphone o lo que sea). Cuando las personas desprevenidas usan este "Wifi gratuito" para iniciar sesión con un formulario HTTP, aunque realiza una POST a HTTPS, el atacante puede ver las credenciales de texto sin formato del usuario mediante el análisis del tráfico de red de su punto de acceso.

Referencias:

+0

exactamente, no lo hagas, pueden oler HTTP. Use HSTS para forzar HTTPS – danday74