Verificación de seguridad del servidor de recursos y autorización OAuth2

1

Estoy a punto de lanzar una API web con OAuth2 para la autenticación (código de autorización, flujos de credenciales implícitas y de cliente). El protocolo se implementa utilizando la biblioteca DotNetOpenAuth v4.3. Aunque es una base de código un tanto antigua, la biblioteca parece sólida (no se pueden encontrar CVE ni quejas importantes).

Pero es mejor prevenir que lamentar, así que, ¿cuáles son las comprobaciones de seguridad que me sugerirían que ejecuten antes de iniciar para garantizar que mi implementación esté bien?

    
pregunta m__ 08.03.2015 - 20:53
fuente

1 respuesta

4

Al actuar como un servidor de autorización (AS) que maneja OAuth 2.0, creo que las dos características principales de seguridad de la biblioteca que debe verificar son:

  1. Evita que se pierda el token de acceso al restringir la URL de redireccionamiento . En el flujo implícito, el AS recibe una concesión de autorización de un cliente en el que no puede confiar. Para no otorgar tokens de acceso a nadie, la biblioteca debería permitirle especificar una lista (blanca) de URL para cada cliente que se conecte. En la prueba de penetración, debe verificar si puede usar una URL en redirect_url que no coincida con una de las URL en la lista blanca (sería un error).

  2. Cómo evitar la falsificación de solicitudes y / o la fijación de sesión entre sitios con el parámetro de estado . El parámetro de estado es un valor aleatorio, generado por el cliente. El parámetro siempre se incluirá en la comunicación posterior con el AS. Permite al cliente validar que el token de acceso que recibe corresponde a la solicitud de autorización precedente. Sin este parámetro, un atacante podría inyectar su propio token de acceso y, por lo tanto, otorgar acceso a los recursos que controla el atacante. El usuario final, entonces, por ejemplo. Publicar sus datos en la cuenta del atacante. Por lo tanto, para la prueba de penetración, debe verificar si la biblioteca valida correctamente el parámetro de estado o si puede modificar el valor.

Ah, y casi lo olvido: OAuth 2.0 especifica claramente que se basa en el transporte seguro SSL / TLS. Entonces, si no está prestando servicio exclusivo a su AS a través de HTTPS, ese es un gran #FAIL en el informe de la prueba de penetración.

La especificación inicial OAuth 2.0 RFC 6749, sección 10 ya contiene muchas consideraciones de seguridad. Además, hay un RFC adicional dedicado a la seguridad de OAuth 2.0: enlace

Otro gran recurso que resume todo se puede encontrar aquí: enlace

    
respondido por el antoinet 30.08.2015 - 22:33
fuente

Lea otras preguntas en las etiquetas