假设公共 SQS 队列的 URL 可以保密是否安全？答案

【问题标题】：Is it safe to assume that the URL of a public SQS queue can be kept secret?假设公共 SQS 队列的 URL 可以保密是否安全？
【发布时间】：2020-12-26 23:49:08
【问题描述】：

我正在创建一个在线食品订购系统，在浏览器中实时显示新订单。

我很想为此使用SQS long polling 功能：

为每个餐厅创建一个 SQS 队列
给每个队列一个伪随机的秘密名称
将其公开，以便浏览器可以直接从队列中读取和删除

鉴于队列 URL 只会出现在给定餐厅的管理区域中，假设无法猜测由伪随机秘密名称组成的 SQS URL 是否安全？

额外问题：有更好的替代方案吗？我会特别考虑一种替代方案，它可以让我为所有餐厅创建一个队列，并使用 websockets 而不是长轮询。

【问题讨论】：

不建议公开 SQS 队列。通常你会通过 api 网关代理。你考虑过吗？
绝不是个好主意！您可以让浏览器通过 AWS Cognito 进行身份验证，然后对 AWS 进行经过身份验证的调用。

标签： amazon-web-services security amazon-sqs long-polling

【解决方案1】：

我强烈建议不要“通过默默无闻来确保安全”。如今，使用自动化脚本在几秒钟内枚举数百万个可能的 URL 非常容易。

我不确定您的用例，但AWS AppSync 是一项非常通用的服务，可能会为您提供解决方案。

【讨论】：

具有足够熵的秘密 URL 与强用户名/密码组合有何不同？ AFAIK 用户名/密码不被视为“通过默默无闻的安全性”？例如，GitHub gists 也使用秘密 URL。
只是一个不同的例子：你可以对某人暴力破解用户名/密码组合采取措施（只要你没有泄露你的哈希值）。根据互联网的性质和 DNS 的工作原理，您无法对枚举子域的攻击者采取任何措施。话虽如此，用户名/密码组合也被认为不是很安全，并且有许多编辑试图转向更强大、更安全的机制，如临时访问密钥、MFA 等。

【解决方案2】：

我同意我不会公开您的队列。我看到了两种可能的解决方案：

队列前面的某种代理。正如建议的那样，您希望您的用户在某个地方登录。这样他们就可以获得一个短期密钥（例如 JWT），该密钥可以通过例如 API 网关进行验证。 API Gateway 将位于您的 Lambda 前面。 API Gateway 让您可以执行 IP 通行证/阻止列表、限制和其他控制等操作。
非 AWS 发布/订阅服务，例如 PubNub。虽然我不能告诉你他们是使用 websockets 还是长轮询，但你真的不在乎 - 这是他们的 Javascript 库。一个优点是他们也有大量的后端库，您可以与之集成。我与 PubNub 没有关联，但过去曾使用过它们。

【讨论】：