如何在我的firebase应用中劫持会话劫持,该应用程序使用AWS Amplify和Congnito进行auth会话?
目前,我已将应用程序部署在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 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
原则上,可以通过以下方式通过:
(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
最后,您可以减少攻击矢量的表面积:
如果Cognito没有这些功能,请考虑使用其他解决方案进行会话管理。在这种情况下,您可以消耗Cognito发送的ID令牌,以为您的应用创建一个新的基于cookie的会话,理想情况下,本届会话应具有所有安全功能。
希望这有帮助!
In principle, detecting session hijacking can be done by:
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:
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!