已完成：
- 我已经在s3 bucket中上传了Kyc文档和附件
- S3与CloudFront集成
- 阻止了S3存储桶中的所有公共访问
- 访问内容的唯一方式是"CloudFront url">
我的要求是：
- 如果"CloudFront Url"已知，任何人都可以访问文档
- 因此，我想限制除我的应用程序之外的URL访问
- 主要阻止chrome、safari和所有浏览器中对该url的访问
是否可以限制URL？怎样
Lambda@Edge在CloudFront处理请求时，将允许您对请求执行几乎任何您想要的操作。
您可以查看用户代理，如果它与您期望的不匹配，则返回403。但是，请注意，更改用户代理字符串并不困难。最好使用身份验证令牌。
老实说，我不太理解你的问题，你应该再次尝试描述这个问题。从鸟瞰图来看，我觉得你在描述IDOR的弱点。但我将在回应中涉及多个部分。
AWS WAF将允许您对各种各样的请求内容执行相当多的阻塞。
特别是对于这个问题，如果您选择使用AWS WAF，您可以执行以下操作来解决这个问题：
- 创建WAF ACL，它不应该是区域性的，应该是全局性的，将WAF ACL的默认操作设置为自动允许
- 构建您想要阻止的regex模式集，或者您可以硬编码特定的示例
- 创建一个规则，阻止具有与正则表达式模式集匹配的
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(层。