¿No es un error de OpenID sobre HTTP (no HTTPS) cuando se usan delegados?

7

Primero, tengo un delegado privado configurado en mi sitio web para OpenID y señalé mi cuenta SE en la URL de mi sitio web; SE no tiene conocimiento del punto final real del proveedor de OpenID hasta que mi respuesta de delegado lo indique.

En segundo lugar, al autenticar en SE y otros, observo que si no escribo explícitamente https: // ... se realiza la solicitud mediante HTTP en lugar de HTTPS.

Tercero, al asociar mi cuenta de SE con mi punto final de OpenID, puedo usar HTTP o HTTPS para iniciar sesión, a pesar de usar HTTPS cuando la cuenta estaba asociada.

Por lo tanto, ¿esto no me abre a un ataque MITM en el que el atacante simplemente modifica la respuesta de mi servidor web para delegar en su propio proveedor de OpenID, y así obtener acceso a mi cuenta de SE?

Nota: no estoy hablando del paso de autenticación real con el proveedor de OpenID, que utiliza HTTPS y redirige a HTTPS si se accede a través de HTTP. Estoy hablando de la solicitud inicial de SE a mi delegado, que SE permite ser hecho usando HTTP porque solo almacenan la URL desde el dominio base en adelante (omitiendo tanto el protocolo como el subdominio) para usar para hacer coincidir una cuenta en lugar de la URL completa.

    
pregunta Lawrence Dol 10.08.2012 - 23:04
fuente

4 respuestas

5

Sí, lo es. Así que siempre debes usar https.

Peor aún, algunos proveedores de servicios violan la especificación:

  

11.5.2. Identificadores de URL HTTP y HTTPS

     

Las partes confiables DEBEN diferenciar entre los identificadores de URL que tienen esquemas diferentes.

Cualquier consumidor / proveedor de servicios que viole esta regla, es vulnerable a un ataque. Esto es especialmente malo porque un usuario no puede protegerse a sí mismo: puede usar https cada vez, pero el atacante solo puede usar http.

Además, no se requiere un hombre en el vector medio. Es suficiente para que el atacante pueda leer el tráfico al proveedor de identidad; en el momento de su elección.

  

Cuando la entrada del usuario final se procesa en una URL, se procesa en una URL HTTP.

Por lo tanto, el comportamiento de StackExchange se cumple en lo que respecta a la configuración predeterminada de http.

La especificación continúa:

  

[...] se RECOMIENDA que se envíe un redireccionamiento desde la URL HTTP a la URL HTTPS. Debido a que las URL de HTTP y HTTPS no son equivalentes y el Identificador que se usa es la URL después de los siguientes redireccionamientos, no se prevé una reducción de la seguridad al usar este esquema.

     

Si un atacante pudiera obtener el control de la URL de HTTP, no tendría ningún efecto en la URL de HTTPS, ya que la URL de HTTP no se usa nunca como identificador, excepto para iniciar el proceso de descubrimiento.

Nota: este enfoque aún es vulnerable en el primer proceso de descubrimiento.

Especificación: enlace

    
respondido por el Hendrik Brummermann 11.08.2012 - 10:53
fuente
2

Sí. Sospecho que cualquiera que pueda MITM StackExchange < - > su sitio web (que, por ejemplo, puede tener un certificado autofirmado) podrá insertar un delegado alternativo de OpenID (en el index.html) y usarlo para ingresar en su cuenta de StackExchange.

    
respondido por el Kevin Cantu 11.08.2012 - 02:52
fuente
0

¿Cuál es la URL del delegado que utiliza? HTTP o HTTPS?

Cuando hace clic en el proveedor de OpenID para Google o en cualquiera de los sitios de OpenID preconfigurados, se le redirige a un sitio de HTTPS.

Solo un proveedor de OpenID que conozco se ocupa de este escenario de forma maravillosa: Symantec Verisign PiP Labs . Una vez que inicie sesión, tiene la opción de NEGAR toda la autenticación inicial creada por una redirección. En su lugar, le piden que inicie sesión directamente en pip.verisignlabs.com y luego navegue hacia Stackoverflow e inicie sesión.

    
respondido por el random65537 10.08.2012 - 23:19
fuente
-1

El problema con esto es que cada inicio de sesión inicia la nueva solicitud HTTPS, que es muy lenta. Es absolutamente muy lento. Pero si se hace correctamente con HTTP / 1.1 con persistencia de conexión keep-alive, no lo es, así que es pura pereza de los desarrolladores ... "¿Quién necesita ssl para la autenticación"? :-)

    
respondido por el Andrew Smith 10.08.2012 - 23:17
fuente

Lea otras preguntas en las etiquetas