2010-07-15 26 views
14

Esto será un poco difícil de explicar, pero haré mi mejor esfuerzo.

Hay un sitio web que tiene el formulario de inicio de sesión en cada página con campos de nombre de usuario/contraseña. Estas páginas no usan SSL. Después de que el usuario rellena el nombre de usuario/contraseña y envía el formulario, el formulario se envía a una página de autenticación que es https.Después de iniciar sesión, ¿deberían todas las páginas ser https?

Tengo algunas preguntas sobre esta situación.

  1. Al enviar un formulario a una página https, ¿los datos están encriptados? ¿O solo después de ir desde una página https (supongo que solo voy a ir)?
  2. Si la respuesta al número uno es la escalera, ¿significa esto que necesitaría usar https para todas las páginas porque el formulario de inicio de sesión se está redirigiendo desde allí?
  3. Después de que un usuario se autentica mediante https, ¿se puede redirigir al usuario a http y continuar utilizando los datos de la sesión? ¿O debería el usuario permanecer en https?
  4. ¿Es mejor/peor dejar al usuario en https?

Muchas gracias por cualquier ayuda!
Metropolis

CONCLUSIÓN

Ok, así que después de pensar en esto por un tiempo he decidido simplemente hacer que todo sea https. @Mathew + @Rook, sus respuestas fueron geniales y creo que ambos lograron grandes puntos. Si estuviese en una situación diferente, podría haber hecho esto de manera diferente, pero aquí están mis razones para hacer todo el asunto https.

  1. Será más fácil controlar las solicitudes de página, ya que solo tengo que permanecer en https.
  2. No estoy demasiado preocupado con la performace (en otra situación que puede haber sido)
  3. no tendrá que preguntarse si los datos de los usuarios que se está asegurando en todos los lugares
  4. estaré siguiendo la pauta de OWASP como Torre declaró

Respuesta

10

De acuerdo con The OWASP top 10 en ningún punto se puede utilizar una identificación de sesión autenticada a través de HTTP. Entonces usted crea una sesión a través de HTTP y luego esa sesión se autentica, luego ha violado el Top 10 de OWASP y está permitiendo que sus usuarios sean susceptibles al ataque.

Recomiendo configurar el secure flag on your cookie. Este es un nombre terrible para esta función, pero obliga a que las cookies sean solo https. Esto no debe confundirse con "Httponly cookies", que es una bandera diferente que es útil para mitigar el impacto de xss.

Para asegurarse de que sus usuarios estén a salvo, forzaría el uso de HTTPS todo el tiempo. ssl es un protocolo muy ligero, si se encuentra con problemas de recursos, entonces considere encadenar sus políticas https.

+0

¿Por qué este sitio web utiliza http todo el tiempo, excepto al iniciar sesión? Tendría que asumir que están usando sesiones? – Metropolis

+0

Sí, como dije, es una compensación. Es posible interceptar y robar una cookie de sesión de StackOverflow. Decidieron que estaban dispuestos a arriesgar esa posibilidad. –

+0

@Metropolis porque esta es una violación owasp muy común. Además, SO no es 100% seguro (http://meta.stackexchange.com/questions/46671/captcha-bypass) – rook

6
  1. Sí. Si la URL de acción es https, los datos del formulario están encriptados.
  2. Debido a # 1 no tiene que hacer que la página sea https, pero puede recibir advertencias de contenido mixto. Y, por supuesto, un atacante hombre en el medio podría manipular la página de inicio de sesión para apuntar a una URL de acción diferente.
  3. Esta es una decisión que debe tomar. Claramente, cualquier información transmitida a través de HTTP, ya sea que las cookies (incluidas las cookies de sesión) o los datos del usuario, puedan ser interceptadas y manipuladas.
  4. Una vez más, se trata de una compensación basada en el rendimiento y la seguridad.
+0

# 3 es una violación owasp. Debería darte un -1 por eso. – rook

+3

@ The Rook, nunca dije que fuera compatible con OWASP de ninguna manera. * * * Dije que HTTP permitía a las personas interceptar y manipular datos de sesión. –

+0

Sí, no creo que estés guiando a la gente por mal camino. – rook

3

Además de lo que dice la Torre, enviar un formulario de http a https es un riesgo para un par de razones:

  1. No hay icono de "candado" en la página donde la gente escriba su nombre de usuario y contraseña, por lo que no tienen forma de saber que sus detalles están encriptados (excepto por "confiar en usted")
  2. Si alguien secuestró su página, sus usuarios no tendrían manera de saber que están a punto de escribir su nombre de usuario y contraseña y ser redirigido a una página maliciosa (esto es un corolario del # 1).

Este es un ataque mucho más simple que la interceptación http galleta, por lo que en realidad es un riesgo aún más grande ...

Pero el punto de La Torre es importante: debe nunca se mezcla tráfico HTTP y HTTPS. En nuestros sitios web, tan pronto como inicie sesión, todo es https a partir de ese momento.

2

Aparte de las respuestas anteriores, ya que las personas tienden a querer ir de HTTPS a HTTP por motivos de rendimiento, this article about HTTPS at Google podría ser de su interés. Su mensaje principal es:

SSL/TLS no es computacionalmente caro más.

+0

El enlace es a imperialviolet.org no a Google como esperaba de "en Google" y el enlace está roto. –

+0

@Stephen P, sí, lamentablemente el enlace está actualmente desactivado. Si busca el enlace en google, debería poder encontrar el artículo en el caché. Si bien es difícil de verificar, hablan de "[su] trabajo en Google". El artículo comienza con "(Este es un resumen de la charla que di en [Velocity 2010] (http://conferences.oreilly.com/velocity) el jueves pasado. Este es un trabajo conjunto de mí mismo, Nagendra Modadugu y Wan -Teh Chang) ", ver http://en.oreilly.com/velocity2010/public/schedule/detail/14217 – Bruno

Cuestiones relacionadas