该服务的技术支持告诉我他们认为此漏洞无关紧要，因为利用此漏洞的唯一方法是获得对用户浏览器历史记录的访问权限。
他们的决定是否正确？我对信息安全还很陌生，但是听起来仍然有些懒惰。
我确实跳过了这个问题，但是在阅读了最受欢迎的答案后，我现在更加关注这个问题被忽略，因为数据是通过GET发送的，并且凭据以纯文本显示。
#1 楼
是的，这是一个漏洞。您可以将它们指向诸如OWASP Top 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
StackExchange
https://stackoverflow.com/questions/26671599/are-security担心在https上使用一个有效的请求发送密码
常见的问题是凭据存储在客户端上-端（浏览器历史记录）和服务器端（Web服务器连接日志），并且有多种方法可以访问该数据。
是的，这是他们的懒惰。他们只考虑自己的代码，而忘记了客户端和基础结构。
评论
stackoverflow链接中引起的一个重要问题是引用标头可能包含带有凭据的查询字符串。因此，技术支持人员断言利用此缺陷的唯一方法是获得对用户浏览器历史记录的访问权限，这完全是错误的，并且也不需要访问服务器。
–雷
18年1月24日在19:08
@Ray OP似乎声明它是在登录时发送的，这限制了在引用标头中使用它的可用性。如果它可以作为会话控制的一种手段持续存在，那么可以肯定，但是我认为情况并非如此。
– schroeder♦
18年1月24日在19:15
@schroeder很大程度上取决于他们登录后立即显示的内容。例如，如果是此站点，那么它将是您决定登录时所处的页面。我也忍不住认为登录方法将与XSS漏洞很好地协同。最后，这样做的真正原因是（通常如此）“为什么要冒险？”
–雷
18年1月24日在19:23
@ray，您当然是对的，但是我试图将我的答案限制为容易在数据泄漏时证明的事情。还有更多的事情可能发生，但最终可能会因情况而异或值得商de。
– schroeder♦
18年1月24日在19:26
任何代理也将记录凭据。 *请注意，但是需要为此进行TLS检查。也许“任何”都是一个好词。
–user2867314
18年1月26日在16:09
#2 楼
机密不属于URL。 URL出现在浏览器历史记录，代理缓存，服务器日志中，并发送给分析服务提供商，并且可能出现在许多您不希望出现机密信息的地方。使用HTTPS（他们确实使用HTTPS，对吗？）只会阻止代理缓存，其他都不会。用户也可能会复制并粘贴URL，而不会注意到其登录凭据仍在其中。
因此，注册和登录应该使用HTTPS POST方法，并将登录凭据放在邮件正文中。
评论
复制粘贴是巨大的。 URL是共享的，如果不共享，则应放在请求参数中而不是URL中。另外，为了方便起见，请在URL中发送搜索参数，以便用户不要共享导致空白搜索页面的URL。
– Qwertie
18年1月25日在4:28
#3 楼
产品安全的第一法则：永远不要相信供应商说安全问题无关紧要。我不会重复已经给出的技术答案。我想对它们进行扩展，并指出，导致他们认为不相关的问题的评估是基于客户环境中可能存在或可能不存在的假设。如果没有对您的环境的深入了解，他们将无法拨打电话。这就像一个汽车公司说，行驶在250公里他们的新车型/ h是完全安全的 - 它可能是在测试赛道上，但在大多数现实世界的道路不会是（公路质量和交通）
一旦您了解了他们的评估有多严重，就会变得很清楚。除了浏览器的历史记录外，GET参数还将显示在代理日志文件中，当有人想要共享链接时，它可能会被错误地邮寄，仅列举两种最明显的其他方式，由于其错误的工程决策，此秘密可能会泄漏出去。
同时考虑到漏洞本身以及对漏洞的不良理解和处理，我将严重怀疑漏洞生产安全产品的能力。我会毫无疑问地让他们知道，然后根据这些新信息重新评估产品。
评论
我不确定您要处理多少安全报告，但是每周我都会收到很少的信息，用户不知道他在说什么。如果时间允许，我尝试解释为什么问题不是问题-有些得到了，有些没有。所以是的-有时候“不适用”或“不相关”的答案是正确的。如果您“永远，永远”信任此类供应商，则意味着您不会与可以准确估算的优质供应商打交道。漏洞悬赏尤其明显-如果您公开运行某个漏洞，则在收到一些“报告”时会迅速改变主意。
– WoJ
18年1月27日在13:19
（续），您将回答“不适用”，“不相关”。现在-有很多公司完全无法应对其安全性或对安全报告的误解。这并不意味着您应该“永远，永远”信任一个与您的观点不同的人。
– WoJ
18年1月27日在13:21
你误会了。安全问题始终是重要的。也许对您而言不对，或者在典型情况下，但始终至少有一个与之相关的客户，并且总是至少有一个可以利用此问题处理更严重问题的攻击者。人们报告的某些问题不是安全问题。但是对于这些内容，您可以解释原因（例如，似乎缺少支票，但是链中稍后有支票）。
–汤姆
18年1月27日在14:14
#4 楼
你是对的。这里有两件事：URL中的凭据
浏览器中的缓存
凭据永远都不应在URL中公开。 URL被记录在很多地方，例如代理服务器，防火墙等。如果我是防火墙管理员或类似的东西，我很高兴窃取该信息。现在，攻击者需要访问浏览器。那么，如果用户使用的是公用计算机呢？他们还会说这是微不足道的吗？如果他们这样做了，伙计，您需要停止使用他们的服务。
评论
值得注意的是：使用URL和/或较短时间窗口后过期的临时身份验证令牌在URL中可以使用可能值得指出的是，对于所发出的请求类型，GET请求几乎肯定是错误的HTTP方法。 URL中的参数很容易使凭据泄漏。浏览器历史记录，链接共享等。实际上，请求应该是带有请求正文中凭据的POST-这样就可以防止这样的琐碎凭据泄漏。
您应该只信任始终使用HTTPS进行身份验证的服务，并使用POST方法传输凭据。这需要有效且受信任的证书（地址栏中的绿色锁定图标）。对单个身份验证有效的安全性令牌（它们是唯一的字符串，而不是凭据）可以显示在URL中，而不会带来安全风险。使用GET进行身份验证是不专业的：可以在日志，历史记录，第三方软件（安全套件/恶意软件/ ...）和浏览器附件中注册凭据。永远不要相信谁不重视您的安全。
通过社交工程POV，任何知道您要访问哪些网站的人都将知道要定位的网站，从而真正可以将您个人描述为个人。我已经看到无数情况，攻击者将其作为枚举和识别阶段的一部分，让您单击链接的一部分，所有这些操作都将您的浏览器历史记录传递给攻击者。