Para evitar la vulnerabilidad, cada solicitud debe estar autenticada de alguna manera y la autenticación verificada . Esto equivale a proporcionar una cookie de sesión, ya sea que lo haga en la URL GET, por ejemplo,
domain.com/details/1234
donde 1234 es su usuario (y también su sesión), o dentro de una solicitud POST o JSON.
En lo anterior, tiene la autenticación, pero no está verificada. Cualquiera puede reclamar ser usuario 1234.
O agrega una cookie separada, que aún expone la identificación del usuario:
domain.com/details/1234:db81390fb2befd1dd839c37ab39d699cddb8d65b
o empacas todo dentro de la cookie:
domain.com/db81390fb2befd1dd839c37ab39d699cddb8d65b/details
Lo anterior tiene la ventaja de que puede internamente reescribir la solicitud después de verificarla
domain.com/details/1234
para que la aplicación "detrás" de la capa de seguridad pueda permanecer sin cambios.
La capa de seguridad extraerá la cookie, verificará que sea válida (puede contener su propia firma criptográfica y un nonce, para evitar los ataques de repetición), y desde la sesión asociada a la cookie recupere la identificación de usuario 1234 y la transmita.
Al autenticarse por primera vez, se genera una nueva sesión y se asocia a la cookie. Si utiliza una cookie "suficientemente grande", puede agregarle aleatoriedad:
1. The mobile app requests the user details:
domain.com/db81390fb2befd1dd839c37ab39d699cddb8d65b/details
2. The server destroys cookie db813... and replies with JSON:
{
'cookie': '926c8a7699c367d3da9370f433189a20b06f8f3d',
...other details...
}
3. The next request will have to contain cookie 926c8... to be accepted.
En el escenario anterior, puede reforzar aún más la seguridad al agregar reconocimiento de estado a la aplicación. Por ejemplo, cuando recibe el JSON anterior, la aplicación móvil se encuentra en estado "Mostrar detalles" y, a partir de ese estado, solo se permite un número muy limitado de transiciones. Es posible que no pueda realizar la transición en un paso desde allí a la pantalla "Cambiar contraseña de usuario", por ejemplo.
Lo que significa que si un atacante puede interceptar la solicitud JSON e intenta usarla para acceder a la función Cambiar contraseña:
domain.com/926c8a7699c367d3da9370f433189a20b06f8f3d/newpassword
se puede identificar como una transición ilegal. El método newpassword "verá" que el estado anterior no fue "Perfil de usuario" o "Menú de seguridad", sino "Mostrar detalles", lo cual no es pertinente, y la conexión se puede cancelar.
El atacante tendría que primero hacer la transición de Detalles al Menú Principal y de allí al Perfil de Usuario, regenerando la cookie una o dos veces y, por lo tanto, eliminando al usuario legítimo . La aplicación de usuario legítima no sabe que su estado ahora no está sincronizado y podría intentar usar la cookie que tiene. Dicha reutilización de cookies puede ser detectada y tomada como evidencia de que una cookie ha sido interceptada intencionalmente. No podrá saber de manera confiable quién es el atacante y quién la víctima, pero puede abortar ambas conexiones.