Autenticación de usuarios en un segundo sitio web con un ID de cadena de consulta de una sola vez: ¿es seguro?

Question

Autenticación de usuarios en un segundo sitio web con un ID de cadena de consulta de una sola vez: ¿es seguro?

#1 de SilverlightFox (2 votos)
#2 de Rápli András (0 votos)
#3 de iainpb (0 votos)
#4 de dandavis (0 votos)

0

Necesitamos autenticar a los usuarios en un segundo sitio web que se 'envía' desde un primer sitio web sin tener que iniciar sesión nuevamente.

La forma en que planeamos hacer esto es para que se envíe un ID de uso único al segundo sitio en una cadena de consulta. Una vez recibido, el segundo sitio se pone en contacto con el primer servidor web a través de un servicio web seguro, que dice "sí" o "no" si el código es original y pueden iniciar sesión.

Todas las comunicaciones serán a través de HTTPS.

¿Hay grandes agujeros de seguridad en esto que hemos pasado por alto? ¿Esto es seguro?

Gracias.

authentication tls

pregunta niico 01.02.2017 - 12:01

fuente

4 respuestas



                    
                Lea otras preguntas en las etiquetas
                                            authentication
                                            tls
                                    
            
        

         
                            RSA o ECDHE para establecimiento de clave?
                                        Pasos para asegurar una cuenta donde un atacante sigue restableciendo la contraseña [cerrado]

score 2 · Answer 1

No es la mejor manera.

Si hay recursos o enlaces de terceros en el sitio de destino, la cadena de consulta en la URL podría revelarse en el encabezado referer .

Además, los parámetros de la cadena de consulta se registran de forma predeterminada en el servidor, lo que significa que un administrador sin escrúpulos puede tener acceso a las sesiones. Lo mismo se aplica a cualquier servidor proxy en ruta que realice inspecciones de nivel de aplicación que tengan instalado un certificado SSL / TLS de confianza.

Un punto más importante es que es visible en la pantalla, por lo que un "surfista de hombro" o una cámara podría recoger el token.

En resumen, el método POST es mucho más seguro porque no tiene los defectos anteriores.

score 0 · Answer 2

Si la generación de ID únicas es lo suficientemente aleatoria, es segura. Quiero decir, por azar, un atacante no debería ser capaz de averiguar las ID válidas que pertenecen a otros usuarios. En el ejemplo, un md5 simple de IDs numéricos o nombres de usuario para autenticación no será seguro. Si utiliza una sal secreta mutuamente conocida en el proceso, lo es. Si no expone el ID de una sola vez al usuario (que no debería por las razones mencionadas anteriormente) y no permite que el usuario lo cambie de ninguna manera. Luego, puede pasar con las ID numéricas simples si valida que la solicitud proviene de la IP del servidor .

score 0 · Answer 3

Por lo general, debe evitar pasar tokens de sesión a través de la URL, ya que proporciona una oportunidad de secuestro de sesión. El hecho de que sean de un solo uso y que estén "verificados" en un segundo canal mitiga esto. Si adopta este enfoque, asegúrese de que los ID de sesión sean lo suficientemente largos y aleatorios, que nunca se reutilicen ni se invaliden de inmediato. Recuerde que si las claves no son lo suficientemente fuertes, dado el tráfico interceptado suficiente, podría determinar claves futuras.

Las cookies pueden ser una opción más segura si se configura en segura y solo en http

Un vector de ataque aquí es su API de verificación de claves, como un atacante estaría buscando formas de agregar mis propias claves a esto, por lo que debe verificar que esté seguro contra ataques de inyección.

Tampoco veo cómo estos identificadores están vinculados a un usuario específico. O también está enviando un ID de usuario con su ID de sesión.

score 0 · Answer 4

Debes usar la parte del fragmento de la URL, en lugar de la parte de la búsqueda para transferir secretos. Por buenas razones mencionadas por otros, los parámetros GET son problemáticos, pero el fragmento de la URL ( #secret ) ni siquiera sale por el cable, lo que hace imposible interceptarlo desde fuera de la computadora.

Esto evita las complicaciones de CORS derivadas de la POSTing de datos en dominios, y en realidad es más seguro que POST porque el secreto permanece local en la máquina.

todo lo que deberías hacer es vincular con un hash en lugar de una consulta:

<a href="https://site2.com/auth?id=abc123 target=_blank>Log In</a>
se convierte en
<a href="https://site2.com/auth#abc123 target=_blank>Log In</a>



 no podrá acceder al secreto pasado del servidor del segundo sitio, pero está disponible para el JS de la página como    location.hash     o más exactamente,    location.hash.slice(1)    . 

 Con respecto al problema menor de la visibilidad humana, puede eliminar el secreto de la barra de URL de la nueva página inmediatamente después de capturar el secreto llamando a    location.hash="";    , o mantenerlo fuera del historial del navegador:    history.replaceState("","","#");    . 

 Si está usando HTTPS todo el tiempo, POST sería tan seguro y permitiría más contenido; El hash (en mis pruebas) está limitado a unos 20kb en navegadores más antiguos. Si solo necesita una clave, el hash es rápido,  físicamente  es seguro, ampliamente compatible y fácil de usar. 

 EDITAR:
A lo largo de esta noción, puede usar otra propiedad, esta visiblemente oculta, llamada    window.name    . AFAIK, no puede usar solo enlaces HTML para esto, se necesita un poco de JS para organizar. Puede usar un iframe solo con HTML, pero necesitará que JS lea el valor de todos modos: 

    <iframe name=secret123 href=https://site2.com/auth></iframe>     

 dentro del marco,    window.name     se establecerá en    secret123    . La propiedad especial    name     se mantiene entre las recargas de la página e incluso la última después de navegar a dominios de terceros, por lo que si la página enmarcada navega, primero debe desinfectar mediante    window.name="";    . 

 también puedes usar fácilmente el "truco" de  nombre  en una ventana emergente js:    window.open("https://site2.com/auth", "secret123");