¿Diseñando un inicio de sesión único con JSONP / CORS?

Navega tus respuestas
9

Me gusta la forma en que OAuth / OpenID puede autenticar / identificar a un usuario de otro dominio, pero solo si el otro dominio lo permite (presumiblemente en las instrucciones del usuario).

Me gustaría hacer algo similar, pero utilizando CORS AJAX o una alternativa como JSONP. El problema es que cuando se usa un redireccionamiento de página completa, el "dominio de inicio de sesión" puede estar seguro de a qué dominio le está suministrando el auth_token / info, porque está emitiendo un propio redireccionamiento HTTP. Sin embargo, eso no es cierto para JSONP.

Mis pensamientos actuales están abajo, y mis preguntas son:

  • ¿Cuáles son las debilidades en este patrón?
  • ¿Hay una forma de hacerlo sin dos solicitudes separadas (para el caso que no es CORS)?

Caso general:

EDITAR: esta sección originalmente asumió una solicitud JSONP; de hecho, creo que podría ser cualquier tipo de datos

Caso A : el usuario ha iniciado sesión en el "dominio de inicio de sesión" (mediante cookies)

  1. El cliente realiza una solicitud al "dominio de inicio de sesión", proporcionando una URL en el "dominio de servicio"
  2. El servidor de inicio de sesión mira la URL suministrada y piensa "sí, está bien", y devuelve una respuesta de redireccionamiento HTTP (3XX) que incluye un auth_token / cualquiera en la URL
  3. El cliente sigue la redirección al dominio de servicio. El dominio de servicio almacena el auth_token / lo que sea en la sesión, y devuelve un recurso estático (por ejemplo, una imagen)
  4. El cliente realiza una segunda solicitud al dominio de servicio (no se permite el origen cruzado) para recuperar el auth_token / lo que sea.

Caso B : el usuario no ha iniciado sesión en el "dominio de inicio de sesión" o no ha autorizado compartir detalles con el "dominio de servicio".

  1. El cliente realiza una solicitud al "dominio de inicio de sesión", proporcionando una URL en el "dominio de servicio"
  2. El servidor de inicio de sesión devuelve una respuesta de Redireccionamiento HTTP (3XX) que incluye un estado "no autorizado" en la URL (o tal vez la URL de un inicio de sesión de estilo OAuth de página completa)
  3. El cliente sigue la redirección al dominio de servicio. El dominio de servicio almacena el estado "no autorizado" en la sesión, devolviendo un recurso estático al cliente.
  4. Luego, el cliente realiza una segunda solicitud al dominio de servicio (no se permite el origen cruzado) para descubrir que la autorización / identificación ha fallado.

Caso C : otro sitio que intenta inspeccionar el estado de inicio de sesión

  1. El usuario navega al sitio dudoso
  2. El cliente realiza una solicitud al servidor de inicio de sesión, suministrando una URL en el actual dominio de servicio
  3. El servidor de inicio de sesión redirige a alguna página en el dominio de servicio real, que devuelve un resultado estático
  4. El usuario puede o no haber iniciado sesión, pero el cliente no puede averiguarlo porque la restricción de origen cruzado prohíbe el punto final del "dominio de servicio" que le indicaría que está prohibido.

CORS AJAX case

Si el punto final del "servidor de inicio de sesión" tiene CORS habilitado, entonces la solicitud podría realizarse como una solicitud AJAX. Si el punto final del "dominio de servicio" no tiene CORS habilitado, el resultado final de esta solicitud AJAX podría ser en realidad un eco de auth_token / lo que sea, en lugar de requerir una segunda solicitud.

  1. El cliente realiza una solicitud de CORS AJAX al "dominio de inicio de sesión", proporcionando una URL en el "dominio de servicio"
  2. El servidor de inicio de sesión devuelve una respuesta de redireccionamiento HTTP (3XX) que incluye el auth_token / failure / lo que sea en la URL
  3. El cliente sigue la redirección al dominio de servicio.
  4. El dominio de servicio devuelve un documento que contiene toda la información proporcionada en la URL (auth_token / whatever).

De hecho, este comportamiento de "eco del símbolo de autenticación" podría incluso usarse en lugar del recurso estático de la sección anterior, por lo que admite ambos modelos con el mismo punto final.

    
pregunta cloudfeet 31.05.2013 - 16:57
fuente

1 respuesta

6

OAuth es flexible y, a veces, el flujo de OAuth se modifica para las necesidades específicas de la aplicación. Los dos flujos más comunes son 2 patas y 3 patas , que si estos flujos se implementan correctamente, generalmente se aceptan como seguros.

La implementación propuesta por CORS AJAX del flujo de OAuth viola dos requisitos de seguridad de RFC-6749 - OAuth 2.0 Marco de autorización . Esta desviación del estándar socava la capacidad del servidor de autorización para validar correctamente el cliente y las intenciones del cliente.

  1. Debe haber un control establecido para evitar que un cliente de JavaScript malintencionado falsifique las interacciones con el servidor de autorización . Si la URL se proporciona como un argumento dentro de una solicitud CORS Ajax, en lugar de verificar el encabezado de origen HTTP , entonces un cliente malicioso puede mentir sobre su contexto. Además, se usa una redirección para la autenticación mutua del servidor de autorización y del cliente. No tener estos controles en su lugar es una violación de RFC-6749 - 10.2. Suplantación del cliente :

      

    Un cliente malintencionado puede suplantar a otro cliente y obtener acceso a recursos protegidos si el cliente suplantado no puede, o no puede, mantener confidenciales sus credenciales de cliente.

         

    El servidor de autorización DEBE autenticar al cliente siempre que sea posible. Si el servidor de autorización no puede autenticar al cliente debido a su naturaleza, el servidor de autorización DEBE solicitar el registro de cualquier URI de redirección utilizado para recibir respuestas de autorización y DEBERÍA utilizar otros medios para proteger a los propietarios de recursos de dichos clientes potencialmente maliciosos. Por ejemplo, el servidor de autorización puede comprometer al propietario del recurso para ayudar a identificar el cliente y su origen.

  2. El flujo de OAuth debe ser iniciado por el usuario. El parámetro de estado OAuth se utiliza para evitar CSRF al establecer la autenticación. Forzar a un usuario a iniciar sesión en una aplicación web es un enlace útil en una cadena de ataques de sesión. Una vez que se ha establecido una sesión, un atacante puede controlar la sesión recién creada mediante CSRF o XSS. El hecho de no probar la intención del usuario en este contexto es una violación de RFC-6749 - 10.12. Falsificación de solicitudes entre sitios :

      

    Un ataque CSRF contra la URI de redirección del cliente permite una   atacante para inyectar su propio código de autorización o token de acceso,   lo que puede resultar en que el cliente use un token de acceso asociado   con los recursos protegidos del atacante en lugar de los de la víctima   (por ejemplo, guardar la información de la cuenta bancaria de la víctima en un   recurso controlado por el atacante).

respondido por el rook 08.09.2014 - 16:36
fuente

Lea otras preguntas en las etiquetas

¿Cómo evitar el cruce de directorios al unir rutas en node.js? ¿Cómo monitorear el tráfico de mi red doméstica?