Campos de contraseña de web segura + http a https redirect

@Hendrik tiene razón al decir que esto es un riesgo de seguridad, ya que una página de inicio de sesión que no sea HTTPS puede permitir que un atacante modifique el enlace de envío antes de que el usuario haga clic en él, sin embargo, hasta el punto en su pregunta sobre webscarab.

Esto (junto con otros proxies) intercepta el tráfico HTTPS (suponiendo que lo hayas configurado como un proxy para todos los protocolos), por lo que no significa necesariamente que el tráfico atravesará Internet de forma clara. Si la publicación fuera a una URL de HTTPS, se cifraría.

Por lo general, puede saber cuándo usa uno de los servidores proxy de intercepción, ya que recibirá un mensaje de error de SSL acerca de que el certificado no coincide (a menos que haya configurado el navegador específicamente para confiar en certificados desde el proxy)

Sí, este es un problema de seguridad porque un atacante puede cambiar el código HTML. Puede cambiar el atributo de acción del formulario para que apunte a su propio servidor. O menos obvio y mejor: agregue un código javascript que refleje la contraseña en su propio servidor sin romper el inicio de sesión en el sitio real.

Lamentablemente, tanto Facebook como Twitter dan un mal ejemplo aquí. Sin embargo, Google Plus redirige a https inmediatamente, por lo que hay algo de esperanza.

¿Qué debes hacer? Informe a los usuarios de que necesitan consultar la barra de direcciones para https y el dominio correcto antes de ingresar cualquier información privada en los formularios web.

Rory tiene toda la razón, pero me gustaría enfatizar que usted (y sus usuarios) deben ser extremadamente cautelosos con los certificados SSL rotos. Hay servidores SSL interceptados en el mundo que pueden leer y modificar cualquier cosa que envíes, basándose en juegos con certificados que llevan exactamente a estos errores.

Si se acostumbra a usted mismo, o peor, a sus usuarios a aceptar errores de certificados, el beneficio de seguridad de SSL desaparece esencialmente ante cualquier persona en la ruta del paquete (por ejemplo, en la misma cafetería o en el mismo hotel, no para mencionar el departamento de TI).

Sé cero sobre webscarab, así que perdóneme si está fuera de contexto, pero siempre debe sospechar cada vez que vea contraseñas de texto sin formato en las capturas de paquetes. Si está enviando contraseñas de texto sin formato en el backend de su aplicación, es mejor que se asegure de comprender las propiedades de seguridad de la red en cuestión.

SSL es barato y fácil. Enciéndelo en cualquier lugar que puedas y sé feliz.

Todavía no he probado webscarab, pero asumo que intercepta el tráfico HTTPS generando certificados https sin firmar. Una página de inicio de sesión http, donde el envío para apunta a un recurso https, debe ser segura. Probablemente haya aceptado un certificado ssl de webscarab en sus sesiones de depuración anteriores, y normalmente recibirá una advertencia al respecto.

Pero, https está roto de muchas maneras. En el caso de la interceptación https, no es necesario generar nuevos certificados SSL. ¿Por qué?

Si el atacante está usando un proxy de intercepción (MiTM), puede reescribir inteligentemente todos los enlaces html de https: // uri's a http: //. ¡Ahora su sitio ya no usa SSL para cifrar datos confidenciales, y el usuario no recibirá ninguna advertencia de certificado SSL, porque no se utilizan!

sslstrip es un proxy que hace exactamente eso.

Una contramedida para esto podría ser ofuscar sus enlaces de tal manera que sslstrip no podrá volver a escribir sus enlaces enlace . Javascripts y CSS vienen a la mente.