我在工作中使用的软件有几个组件，我们称它们为服务器和代理。

服务器通过 https 运行一个 api，代理使用该 API 与之通信。

服务器可以是云托管或本地托管的。

通过在请求的标头中提供给定代理的 guid，无需任何身份验证过程即可访问整个 api。该 api 也可供非代理使用（尽管可用的已发布功能与相同的 api 略有不同，没有特殊限制来识别它是代理还是来自任何人的随机 http 请求）

这些 guid 在服务器应用程序的 Web 前端中不可见，在代理应用程序的 gui 中也不可见。并且代理不会在用户机器上运行——更像是 IT 人员只访问虚拟机。

该 API 允许提取密码和其他加密存储在数据库中的数据。根据您对该软件的信任程度，您可能会在其中存储一些非常强大的凭据。

guid 似乎是使用版本 4 生成的 .net 我认为它被称为（对不起，我的安全知识有限），因为第三组的第一个字符在 MS 格式中是 4，​​我看不到任何代码用于创建 guid 的 db 及其托管 api 的 asp.net Web 应用程序。

对 api 的调用似乎没有速率限制，即使对于多个未经授权的请求，似乎也没有进行子网或 IP 地址过滤 - 显然甚至在云实例上也没有（尽管我再次不是安全人员，也许我现在在观察名单上，我发送给他们的所有东西都会受到不同的对待）

这些 guid 未加密地存储在服务器应用程序数据库中。

我向供应商提出了这个作为一张票，他们基本上说它是按照设计的，值得称赞的是，他们对此进行了非常快的调查（考虑到公司的明显规模）。

我疯狂地认为这很糟糕吗？

似乎现在任何拥有数据库访问、代理访问或网络硬件访问的人现在都能够获得他们想要的任何东西。由于某种原因（例如，您使用云实例并且在很短的时间内有人设法在中间人），以及由于某些原因导致 https 流量暂时失败，并且在您删除这些代理之前，您都是敞开的。甚至没有记录访问以提取凭据？- 至少从我作为客户的角度来看，我没有看到它（除非我去查看本地实例上的 IIS 日志，我猜是这样）。

显然无法预测 guid（因为我无法向云实例注册一堆代理并预测下一个客户 guid 将是什么）但如果我使用 api 进行身份验证，我得到的一次性访问令牌是很多的，这似乎很奇怪比 guid 复杂几倍，但只对那个会话有效，而 guid 基本上永远持续下去。

您可以在逻辑上划分代理以限制他们可以访问的数据，现在我已经发现了这个潜在的漏洞，这突然变得非常重要，所以也许我只是让企业意识到这一点等等？

对于这种类型的应用程序，也许没有办法解决这个问题，我从来没有写过这样的东西。但至少我希望有人尝试收紧这一限制

• 将此密钥的使用限制为已知的 IP 地址（或至少在 IP 地址更改或使其成为选项时生成警告）
• 仅在初始握手中使用密钥，然后从那里使用令牌，因此并非所有流量都容易受到攻击
• 每次代理成功连接到服务器时，可能会创建一个新的这些密钥

我不知道，正如我所说我从未编写过服务器代理类型的应用程序，也许我只是天真？