阻止从chrome、safari和所有浏览器访问Aws cloudfront url



已完成:

  1. 我已经在s3 bucket中上传了Kyc文档和附件
  2. S3与CloudFront集成
  3. 阻止了S3存储桶中的所有公共访问
  4. 访问内容的唯一方式是"CloudFront url">

我的要求是:

  1. 如果"CloudFront Url"已知,任何人都可以访问文档
  2. 因此,我想限制除我的应用程序之外的URL访问
  3. 主要阻止chrome、safari所有浏览器中对该url的访问

是否可以限制URL?怎样

Lambda@Edge在CloudFront处理请求时,将允许您对请求执行几乎任何您想要的操作。

您可以查看用户代理,如果它与您期望的不匹配,则返回403。但是,请注意,更改用户代理字符串并不困难。最好使用身份验证令牌。

老实说,我不太理解你的问题,你应该再次尝试描述这个问题。从鸟瞰图来看,我觉得你在描述IDOR的弱点。但我将在回应中涉及多个部分。

AWS WAF将允许您对各种各样的请求内容执行相当多的阻塞。

特别是对于这个问题,如果您选择使用AWS WAF,您可以执行以下操作来解决这个问题:

  1. 创建WAF ACL,它不应该是区域性的,应该是全局性的,将WAF ACL的默认操作设置为自动允许
  2. 构建您想要阻止的regex模式集,或者您可以硬编码特定的示例
  3. 创建一个规则,阻止具有与正则表达式模式集匹配的User-Agent标头的请求

但归根结底,你可能只是在打一场一开始就不一定要打的仗。这样想吧,如果你想屏蔽所有象征浏览器的User-Agent头,那没关系。但问题是,User-Agent标头很容易被覆盖和欺骗,这样你就看不到典型的浏览器User-Agent标头。我不建议你根据这个标准阻止请求,因为在一天结束时,我只需要使用一个代理,让它在将流量转发到服务器之前替换请求内容,绕过WAF,甚至Lambda@Edge.

我建议制定某种授权/身份验证要求来访问这些特定文件。由于KYC可能是敏感的,这将是一个很好的控制措施,以确保那些不应该访问文件的人不会访问这些文件。

在我看来,您似乎遇到了攻击者可以利用IDOR漏洞的情况。如果是这种情况,则需要在应用程序层中对该逻辑进行编程。在AWS WAF层将无法防止这种情况。

如果你真的想解决这个问题,并且你正在处理IDOR,我会使用Lambda@Edge以验证请求中包括的CCD_ 5应该能够访问KYC文档。您应该在数据库中存储特定用户可以访问的KYC文档,并检查Cookies标头是否包括上传KYC文档的用户的Cookies。这将有效地实现授权/身份验证,但不是仅在应用程序层,而是在Lambda@Edge(或CDN(层。

相关内容

  • 没有找到相关文章