Actualmente tengo mi aplicación implementada en Firebase y uso AWS Amplify con AWS Cognito para autenticar usuarios y sesiones.
El equipo de seguridad informó que se trata de una vulnerabilidad de secuestro de sesión.
# Used Cookie [ { "domain": "my_domain.firebaseapp.com", "expirationDate": 1654892898, "hostOnly": true, "httpOnly": false, "name": "IdToken", "path": "/", "sameSite": null, "secure": false, "session": false, "storeId": null, "value": "XXXXXXX" } ] # LocalStorage { "CognitoIdentityServiceProvider.MY_ID_CLIENT_APP.LastAuthUser": "MY_SAML_PROVIDER", "CognitoIdentityServiceProvider.MY_ID_CLIENT_APP.MY_SAML_PROVIDER.accessToken": "XXXXX", "amplify-redirected-from-hosted-ui": "true", "CognitoIdentityServiceProvider.MY_ID_CLIENT_APP.MY_SAML_PROVIDER.idToken": "XXXXX", "amplify-signin-with-hostedUI": "true", "CognitoIdentityServiceProvider.MY_ID_CLIENT_APP.MY_SAML_PROVIDER.clockDrift": "0", "CognitoIdentityServiceProvider.MY_ID_CLIENT_APP.MY_SAML_PROVIDER.refreshToken": "XXXXX" }Mi código usa:
//Verify Session useEffect(() => { const paths = queryString.parse(window.location.search) if (!state.NotLogin) { if (paths.code && paths.state) { setloadHosted(true) } Auth.currentAuthenticatedUser().then(res=> { let finalUser = "" let usernameCognito = res.username.split("_") if (usernameCognito.length === 2) { finalUser = usernameCognito[1] } else { finalUser = usernameCognito } sweetAlert(`Welcome, ${finalUser}`, "success") Cookies.set('IdToken', res.signInUserSession.idToken.jwtToken, { expires: 1 }) actions({ type: "setState", payload: { ...state, username: finalUser } }) setloadHosted(false) setShowOption(true) }) } else{ setShowOption(true) } }, [])En principio, la detección del secuestro de sesión se puede realizar mediante:
El (1) método requiere que almacene la dirección IP de la solicitud de inicio/registro en el token de sesión/JWT creado. En cada solicitud posterior, verificaría que la IP en el token sea la misma que la IP de la solicitud. De lo contrario, puede devolver un 401. Si bien este método agrega una capa adicional de protección, puede generar falsos negativos/positivos (por ejemplo, qué sucede si el usuario comienza a usar una VPN).
El método (2) es más robusto, pero mucho más complejo de implementar. En pocas palabras, debe cambiar el token de actualización en cada uso (no estoy seguro de si cognito tiene eso), y si se usa un token de actualización anterior después de que ya se emitió uno nuevo, entonces es un robo de sesión. Esto casi no tiene falsos positivos o negativos, suponiendo que la implementación se realice correctamente. Entrar en los detalles de implementación en esta respuesta sería difícil, por lo que estoy vinculando un blog: https://supertokens.com/blog/the-best-way-to-securely-manage-user-sessions
Finalmente, puede disminuir el área de superficie del vector de ataque:
Si Cognito no tiene algunas de estas características, considere usar una solución diferente para la administración de sesiones. En este caso, puede consumir el token de ID enviado por Cognito para crear una nueva sesión basada en cookies para su aplicación y, idealmente, esta sesión debería tener todas las funciones de seguridad.
¡Espero que esto ayude!