【问题标题】:Are AWS Cognito User Pool ID and App Client ID secret?AWS Cognito 用户池 ID 和应用程序客户端 ID 是保密的吗?
【发布时间】:2020-10-23 10:49:52
【问题描述】:

所以 2 个问题。

  1. 是 Aws Cognito 用户池的 UserPoolId 和 AppClientId 密码吗?
  2. 如果是这样,您如何确保它们的安全?我见过的所有库 (aws-amplify/amazon-cognito-identity-js) 似乎都是完全基于客户端的。

我在这里错过了什么。似乎您通过这两条信息向任何具有 JS 访问密钥的恶意用户提供 Cognito 王国。

【问题讨论】:

    标签: security amazon-cognito


    【解决方案1】:

    它们不是秘密。

    实际上,ID 令牌包含 iss 声明(属性),即用户池 ID,以及 aud 声明,即应用客户端 ID。

    访问令牌包含 iss 声明,这也是用户池 ID,而 client_id 声明表示应用客户端 ID。

    如果这些令牌中的任何一个被不良行为者截获,那么他们可以解码这些令牌,因为它们只是 base64 编码(未加密)。

    但是,只要 JWT 得到正确验证,仅仅知道这 2 条信息通常对攻击者来说并不是非常有用。

    它不会让攻击者访问用户池本身,因为这需要 AWS 凭证,这些凭证只分配给用户,或者已经过正确身份验证的身份(然后由 ID 池颁发凭证)。

    在访问 api 方面,攻击者可能希望以某种方式修改有效负载以更改请求中的数据。例如,他们可能希望将假设的role 声明从user 更改为admin,以提升他们不应升级的权限和访问区域。通过在服务器端正确验证 JWT 令牌以确保有效负载未被篡改,可以缓解这种情况。

    另一种类型的 api 攻击可能是使用一个经过正确身份验证的令牌来访问另一个 api(JWT 替换)。这可以通过验证 issaud 声明来缓解,以确认 JWT 是专门发布给预期的用户池和应用程序客户端的。

    【讨论】:

    • 谢谢,这让我的事情变得更容易了,我对现有的设计感觉更好。很好解释的答案!
    • 但是如果攻击者使用 userpool ID 和 appClientId 来设置一个客户端,在给定的用户池中创建数千个用户,那该怎么办?这可能会用假用户填满用户池......
    • @BrunoNegrãoZica 鉴于机器人和虚假账户的数量,我想这是一个连 Twitter 和 Facebook 都存在问题的问题。知道他们如何监控它会很有趣。我想知道他们是否使用 AI 来对帐户中的行为进行分类?
    • 是的,监控!我发现 Cognito 会向 cloudwatch 发送“SignUp”事件,而 cloudwatch 有一个称为“异常检测”的功能,它使用 AI 来区分正常使用情况和不正常使用情况,从而触发警报。还有“Cloudtrail”,它将客户端 API 调用的 IP 地址记录到 Cognito。
    • 我不认为暴露这些有什么害处。甚至 AWS Amplify 也将 aws-exports.js 文件存储在客户端,其中包含所有这些值,包括您的 dyanmodb 表名称、api 路径、s3 存储桶名称等
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-05-07
    • 1970-01-01
    • 2019-10-07
    • 1970-01-01
    • 2018-05-20
    • 2023-03-05
    • 1970-01-01
    相关资源
    最近更新 更多