是的。这是一个问题——一个大问题。最近，我在一家企业的网店中发现了一个设计缺陷，它允许我在其他访问者的图表中插入无辜的注释。

看起来很无辜，而且很烦人，直到我进一步观察并发现我也能够将 Javascript 代码 (XSS) 插入到这些笔记中。所以换句话说，我可以在每个访问者的图表上利用 XSS。我做了一个快速的 PoC，向他们展示了如何使用该设计缺陷、XSS、BeEF 和 Metasploit 轻松破解任何访问者的计算机（在这种情况下，我自己是一个 PoC）。

因此，即使是最小的缺陷也可能最终导致巨大的风险。

除此之外，谁说您发现的错误是该网站的开发人员唯一犯的错误？也许他还犯了很多其他错误。

报告将是您能做的最好的事情——即使看起来没有必要。

您的问题是：如果安全漏洞不会造成太大危害，那么安全漏洞是否可以接受？

答案是肯定的，如果在了解后果的情况下由企业决定。

您所做的称为风险评估。对于每个风险，您必须在实例化时突出显示对您公司的影响。根据该评估，您（您 = 有权做出业务决策的人）有三个选择：

• 您可以接受它-假设修复它的成本不值得后果
• 您可以减轻它：将其修复到您可以接受后果的程度
• 您可以为它投保——有效地将风险转移给其他人。

可以想象，风险评估中有几个热点领域。

第一个是评估后果和概率。有很多关于如何做到这一点的书籍和文章，归根结底，这是基于有力的挥手和经验。输出永远不会像书中的那样

我们有 76% 的可能性发生这种情况，这将花费我们 126,653 欧元

反而

好吧，我觉得这是我们应该注意的风险

请注意，“后果”部分有时可能是可量化的（例如在线商务的利润损失），但通常不是（例如您公司的形象损失）。

除了风险评估的可疑理论方面之外，您还应该始终利用一个巨大的优势：您将风险摆在桌面上，并且必须以某种方式处理它。

这不仅是一个后背失去其高贵名称的地方，它是突出信息安全工作应该去哪里的正确工具。它还提高了你的知名度（没有那么多主动的案例可以提高你的知名度），并迫使你对什么是重要的，什么是不重要的进行严格、深入、务实的审视。

我看到这样一个简单的密码重置方案的问题是它暗示了平台中的更多漏洞。一个有缺陷的安全概念很少被孤立到只发生一次，因为这些缺陷通常与开发人员的安全实践有关。至少，我怀疑他们的内部登录程序也可能受到相同缺陷的影响，可能允许攻击者访问他们通常不应该访问的数据库、代码和进程。

从那里，可能会修改服务器的代码以报告明文密码，或收集其他私人信息，并可能允许对其他系统的攻击。毕竟，即使是 2016 年，仍然有很多人仍然使用与 Facebook 相同的银行账户密码，尽管这样做存在明显的风险。即使没有，将昵称与电子邮件地址相关联也可能会使用户的其他帐户面临风险；攻击者对用户帐户了解的信息越多，他们就越能利用尝试破坏同一个人拥有的其他帐户。

至少，我建议您联系网站所有者，看看他们是否会解决问题，如果没有，请考虑不要使用他们的应用程序，除非绝对必要。我还建议您将用户帐户上的电子邮件更改为未连接到您关心的电子邮件地址的一次性帐户。我们不再处于一个可以假设明显的小缺陷以后不会再困扰我们的时代。

如果我没看错，他们可以更改任何帐户的电子邮件地址和密码，然后启动修复表单并通过邮件继续修复过程。

支持团队可能会假设电子邮件地址是合法的，并且可以与收件人交换敏感信息 - 如果它是一位认识的客户，您甚至可以开始处理通过网站/邮件收到的订单。

另一个问题可能是您是否可以访问联系历史记录或维修订单历史记录？也许客户在他的维修订单中写入了机密信息，或者甚至订单的数量和类型都可能揭示他的业务问题？

另一个问题可能是客户邮件地址的大量垃圾邮件。如果我调用你的密码重置一百万次，它会向你的用户发送一百万封邮件，不仅填满他们的收件箱，还会让你进入几个垃圾邮件过滤器列表......之后从这些列表中删除。

如果我只需要枚举昵称并且可以重置所有帐户密码，DoS 当然很容易。

但最大的问题是错误的安全感

可能是我们忽略了当前存在的某个角度或问题。但即使现在没有任何问题 - 如果有人决定明年在此页面中实现新功能怎么办？也许让客户在线订购/付款。- 您提供了一个只能通过用户名和密码访问的上下文，人们和开发人员将依赖它。每个人都会认为“这是应用程序的一个安全部分，只能由客户访问，所以我可以做 X 并依赖 Y”

如果一个应用程序实际上是可公开访问的，它应该看起来是这样。如果应用程序看起来安全，它应该是安全的！