如何在我的firebase应用中劫持会话劫持,该应用程序使用AWS Amplify和Congnito进行auth会话?

发布于 2025-02-08 02:00:06 字数 2075 浏览 2 评论 0原文

目前,我已将应用程序部署在Firebase上,并使用AWS放大了AWS Cognito进行身份验证的用户和会话

# 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"
}

我的代码使用:

    //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)
        }
    }, [])

Currently I have my App deployed on Firebase and using AWS Amplify with AWS Cognito for authenticate users and Sessions

The security Team reported that is a Session HIjacking vulnerability.

# 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"
}

My code uses:

    //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)
        }
    }, [])

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

一花一树开 2025-02-15 02:00:06

原则上,可以通过以下方式通过:

  1. 将会话绑定到IP地址
  2. 使用旋转刷新令牌

(1)方法,要求您将登录IP地址存储在创建的JWT / Session Token中。在每个后续请求中,您将检查令牌中的IP是否与请求的IP相同。如果没有,您可以返回401。虽然此方法添加了额外的保护层,但它可能会导致虚假响应 /阳性(例如,如果用户开始使用VPN,该怎么办)。

方法(2)更强大,但实施更为复杂。简而言之,您需要更改每种用途上的刷新令牌(不确定Cognito是否有),如果已经发出了新的刷新后,则使用以前的刷新令牌,那么这是一个会话盗窃。假设实施正确完成,这几乎没有误报或负面因素。在此答案中进入实现细节将很困难,因此我正在链接一个博客: https://supertokens.com/blog/the-best-way-to-to-securely-manage-manage-user-sessions

最后,您可以减少攻击矢量的表面积:

  • 使用 : httponly cookie存储会话令牌,这将防止通过XSS盗窃XSS
  • 启用JWT签名键的旋转(不确定Cognito是否具有该键,但如果这样做,请启用它)。
  • 为访问令牌留下短时的时间,并为刷新令牌长寿。这样,如果访问令牌受到损害,则风险是有限的。如果刷新令牌受到损害,则会盗窃检测可以启动(假设您使用的是旋转刷新令牌),
  • 请确保防止CSRF攻击。
  • 如果您自己存储会话令牌,请确保仅存储它们的Hashed版本。如果DB受到损害,这将限制他们的利用。

如果Cognito没有这些功能,请考虑使用其他解决方案进行会话管理。在这种情况下,您可以消耗Cognito发送的ID令牌,以为您的应用创建一个新的基于cookie的会话,理想情况下,本届会话应具有所有安全功能。

希望这有帮助!

In principle, detecting session hijacking can be done by:

  1. Tying a session to an IP address
  2. Using rotating refresh tokens

The (1) method, requires you to store the IP address of the sign in / up request in the created JWT / session token. On each subsequent request, you would check that the IP in the token is the same as the IP of the request. If not, you can return a 401. Whilst this method adds an extra layer of protection, it can result in false negatives / positives (For example, what if the user starts to use a VPN).

Method (2) is more robust, but much more complex to implement. In a nutshell, you need to change the refresh token on each use (Not sure if cognito has that), and if a previous refresh token is used after a new one is already issued, then it's a session theft. This has almost no false positives or negatives, assuming that the implementation is done correctly. Going into the implementation details in this answer would be difficult, so I am linking a blog: https://supertokens.com/blog/the-best-way-to-securely-manage-user-sessions

Finally, you can decrease the surface area of the attack vector:

  • Use httpOnly cookies to store session tokens which will prevent token theft via XSS
  • Enable rotation of JWT signing keys (not sure if Cognito has that, but if they do, enable it).
  • Keep a short lifetime for the access token and a long lifetime for the refresh token. This way, in case the access token is compromised, then the risk is limited. If the refresh token is compromised, then session theft detection can kick in (assuming that you are using rotating refresh tokens)
  • Be sure to protect against CSRF attacks.
  • If you are storing session tokens yourself, be sure to store only their hashed version in the db. This limits their exploit in case the db is compromised.

If Cognito doesn't have some of these features, consider using a different solution for session management. In this case, you can consume the ID token sent by Cognito to create a new cookie based session for your app, and ideally this session should have all the security features.

Hope this helps!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文