Iniciar sesión en Google+: flujo de código de un solo uso versus flujo del lado del servidor puro

4

Estoy leyendo la documentación sobre el inicio de sesión de Google+, más específicamente, su flujo del lado del servidor. Dice ( enlace ) que el flujo de código de un solo uso tiene ventajas de seguridad sobre el lado del servidor puro fluir. Dice:

  

"Este flujo de código de una sola vez tiene ventajas de seguridad tanto para un puro   flujo del lado del servidor y sobre el envío de tokens de acceso a su servidor. "

Puedo ver las ventajas del flujo de código de un solo uso frente al envío del token de acceso al servidor, pero realmente no puedo ver las ventajas del flujo de código de un solo uso frente al flujo del lado del servidor. Me preguntaba si alguien puede señalar algunos de ellos.

    
pregunta markovuksanovic 13.09.2014 - 12:01
fuente

2 respuestas

4

Parece que la única ventaja de seguridad es que si se usa un flujo de código único, el componente del navegador y el componente del servidor del cliente obtienen su propio token. En el flujo del lado del servidor puro, solo el servidor obtiene el token y el flujo de la aplicación web, solo el cliente obtiene el token. El envío del token del cliente al servidor, y viceversa, expone al usuario final a un cierto riesgo. Al usar el flujo de código de una sola vez, no hay token de envío desde el cliente < - > El servidor y el riesgo de que los tokens se vean comprometidos es menor.

    
respondido por el markovuksanovic 27.09.2014 - 15:59
fuente
1

"Este flujo de código único tiene ventajas de seguridad ..." La afirmación es absolutamente válida si se considera uno de los ataques más peligrosos que puede sufrir una aplicación web. Es la falsificación de solicitudes en sitios cruzados (CSRF en breve).

Antes de explicar la ventaja del código de un solo uso, permítame aclarar el concepto de CSRF. CSRF es el número 8 en la lista de OWASP de las vulnerabilidades más peligrosas en 2013. Si una aplicación web es vulnerable a CSRF, entonces es posible ejecutar cualquier script para el pirata informático en el extremo del usuario, siempre que el usuario deba haber iniciado sesión. Básicamente, qué sucede si el atacante creará urls o solicitudes POST que contengan códigos maliciosos, pueden ser incluso los códigos JS para capturar las cookies de sesión del usuario y enviarlas al pirata informático. Ahora estas direcciones URL se envían al usuario de destino a través de correos electrónicos y chats. Las solicitudes POST son implementadas en su propio sitio por el pirata informático y el enlace se entrega a la víctima de la misma manera. Dado que el usuario ha iniciado sesión, una vez que haga clic en el enlace, las secuencias de comandos ocultas se ejecutarán al final del usuario y será hackeado.

El único método de prevención posible contra CSRF es mediante la implementación de tokens en cada página. Una vez que el usuario inicia sesión en su cuenta, el servidor asigna tokens CSRF a cada página de la aplicación web. Ahora que cada vez que se hace clic en los enlaces, el token CSRF se envía al servidor y el servidor solo da permiso si acepta ese token. Lo que tenga que pensar es que un enlace al correo electrónico o al chat tendrá un token CSRF diferente y, por lo tanto, evita este ataque.

    
respondido por el Anandu M Das 22.09.2014 - 16:52
fuente

Lea otras preguntas en las etiquetas