是的，这是一个漏洞。您可以将它们指向这些威严的机构，例如

• OWASP 前 10 名

  • https://www.owasp.org/index.php/Information_exposure_through_query_strings_in_url
  • https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management
• CWE
  • 通过 GET 请求中的查询字符串公开信息https://cwe.mitre.org/data/definitions/598.html
  • 凭证保护不足https://cwe.mitre.org/data/definitions/522.html
• 堆栈交换
  • https://stackoverflow.com/questions/26671599/are-security-concerns-sending-a-password-using-a-get-request-over-https-valid

常见的问题是凭据以明文形式（浏览器历史记录）和服务器端（网络服务器连接日志）存储在客户端，并且有多种方法可以访问该数据。

是的，这是他们的懒惰。他们只考虑他们的代码，而忘记了客户端和基础设施。

秘密不属于 URL。URL 出现在浏览器历史记录、代理缓存、服务器日志中，被发送给分析服务提供商，并且可以出现在您不希望秘密信息出现的许多其他地方。使用 HTTPS（他们确实使用 HTTPS，对吗？）只会阻止代理缓存，其他都不会。

用户也可能会复制和粘贴 URL，而不会注意到他们的登录凭据仍在其中。

因此，注册和登录应使用 HTTPS POST 方法和消息正文中的登录凭据。

产品安全的第一条规则：永远不要相信供应商会说安全问题无关紧要。

我不会重复已经给出的技术答案。我想对它们进行扩展并指出，导致他们将问题评估为无关紧要的评估是基于在客户环境中可能成立也可能不成立的假设。如果没有对您的环境有充分的了解，他们就无法做出这个决定。这就像一家汽车公司说，以 250 公里/小时的速度驾驶他们的新车型是非常安全的——它可能在测试轨道上，但在大多数现实世界的道路上它不会是（道路质量和交通）。

一旦您了解他们的评估有多大缺陷，这一点就会变得清晰。除了浏览器历史记录之外，GET 参数也将显示在代理日志文件中，当有人想要共享链接时，它可能会被错误地邮寄，仅举两个最明显的其他方式，由于他们糟糕的工程决策，这个秘密可能会泄露.

考虑到漏洞本身以及他们围绕它的错误推理和处理，我会严重怀疑他们制造安全产品的能力。我会毫不含糊地让他们知道，并根据这些新信息重新评估产品。

你说的对。这里有两件事：

1. URL 中的凭据
2. 在浏览器中缓存

凭据不应在 URL 中公开。URL 记录在很多地方，例如代理服务器、防火墙等。如果我是防火墙管理员或类似的东西，我会很高兴窃取这些信息。现在他们的观点是攻击者需要访问浏览器。那么如果用户使用的是公共计算机呢？他们还会说它微不足道吗？如果他们这样做了，伙计，你需要停止使用他们的服务。