如果安全缺陷不会造成太大的危害，是否可以接受？

#1 楼

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

是的，如果由企业在了解后果的同时做出决定。

您是什么？这样做称为风险评估。对于每种风险，您必须在实例化时突出其对公司的后果。根据该评估，您（您=有权做出业务决策的人）有三种选择：


您可以接受-假设修复它的成本没有值得承担的后果
您可以减轻它：将其修复到可以接受后果的程度
您可以保证避免后果-有效地将风险转移给其他人。

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

第一个是后果和可能性的评估。关于如何执行此操作的书籍和文章很多，最终，这是基于强烈的挥手和经验。输出永远不会像书中的输出那样


我们有76％的可能性发生，这将使我们损失126,653€


但宁可


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


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

除了风险评估的可疑理论方面，您还应该始终拥有一个巨大的优势利用：您将风险置于桌面上，必须以某种方式加以处理。

这不仅是一个背后失去其高贵名称的地方，而且是突出显示信息安全工作应该去哪里的正确工具。它还提高了您的可见性（没有那么多主动式案例可以提高您的可见性），并迫使您对重要和不重要的内容进行认真，深刻，务实的了解。

#2 楼

是。这是一个问题-一个大问题。
我最近在一家企业的网上商店中发现了一个设计缺陷，该缺陷使我可以在其他访问者的图表中插入无辜的注释。

看起来很无辜，而且只有烦人，直到我进一步查看并发现我还能够在这些注释中插入Javascript代码（XSS）。因此，换句话说，我可以在每个访问者的图表上利用XSS。
我做了一个快速的PoC，向他们展示了如何利用该设计缺陷轻松地破解任何访问者的计算机（在本例中，我是PoC）。 ，XSS，BeEF和Metasploit。

所以即使是最小的缺陷也可能会带来很大的风险。

除此之外，谁说您发现的错误是
也许他也犯了很多其他错误。

报告是您最好的方法，即使看起来不必要。

#3 楼

我看到的使用这种简单的密码重置方案的问题是，它提示了该平台中的其他漏洞。有缺陷的安全性概念很少如此孤立，只能发生一次，因为此类缺陷通常与开发人员在安全性方面的实践有关。至少，我怀疑他们的内部登录过程也可能会受到同一漏洞的影响，从而可能使攻击者访问他们通常不应该访问的数据库，代码和进程。

来自在那里，可能可以修改服务器的代码以报告明文密码，或收集其他私人信息，并可能允许对其他系统的攻击。毕竟，即使是在2016年，尽管这样做存在明显的风险，但仍有许多人仍在使用与Facebook相同的银行帐户密码。即使没有，将昵称与电子邮件地址相关联也可能使用户拥有其他帐户的风险；攻击者知道的有关用户帐户的信息越多，他们越有可能利用其意图来颠覆同一个人拥有的其他帐户。

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

#4 楼

如果我正确地看到此情况，他们可以更改任何帐户的电子邮件地址和密码，然后启动修复表格并通过邮件继续进行修复过程。

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

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

另一个问题可能是客户邮件地址的大量垃圾邮件。如果我调用您的密码重置一百万次，它将向您的用户发送一百万封邮件，不仅会填充他们的收件箱，还会使您进入多个垃圾邮件过滤器列表中……在这方面，获取服务器可能很麻烦然后从这些列表中删除。

DoS当然非常简单，如果我只需要枚举昵称并可以重置所有帐户密码。

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

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

如果应用程序实际上是公共可访问的，则应看起来像它是。如果应用程序看起来很安全，那么它应该是安全的！

#5 楼

这里有两种观点：


作为用户，我会很担心，我会让所有者知道，并且我不会在该网站上共享任何敏感信息。
作为网站所有者/开发人员，您有责任评估任何潜在的安全风险是否严重到足以使您付出努力的程度。并非每种风险都会严重到足以证明采取措施的合理性，这要根据发生的可能性，违反的影响以及控制该风险所需的努力来判断。

在这种情况下，您已经猜测）：


严重性：低
可能性：中等
努力：低

，所以他们可能应该对此做些事情;

在一般情况下，针对您的问题“如果安全漏洞不会造成太大危害，是否可以接受安全漏洞？” -是的，可以。您需要确定严重性/可能性/努力权衡是否值得解决问题。在许多情况下，“接受风险”是一个完全合理的应对措施。


作为一个极端的例子，“可以破坏强大加密货币的外星人访问地球”是我的业务面临的风险。我选择不控制该风险，因为它发生的可能性非常低，因此不值得。

#6 楼

这是一个好问题，不容易回答。

每个安全风险就是这样，就是一种风险。解决该风险需要权衡提议的解决方案的成本，混乱和风险危险。

查看您的特定问题，您拥有网站的“私有”部分，其中包含一些信息，但是访问该网站的那部分人不会造成真正的伤害。您的安全漏洞还要求黑客必须知道每个密码都重置为同一事物，以及该事物是什么。

所以，今天，今天，您最大的风险是无风险或至少较低。

明天最大的风险是私人部门可能拥有机密信息。

“修复”的成本似乎很小。特别是如果您已经邮寄了新的“固定”密码。本质上，只需将密码分配更改为随机的一个即可，并且此问题现在已“修复”。它可能不是最好的，但是更好。

因此，您的修复成本很低，但安全风险却很低。您需要将其与业务需求进行权衡并确定是否值得。

请记住，业务可能会使用该固定密码。例如，支持人员可能已经受过训练，可以重设密码，然后在电话上告诉用户新密码，并与他们待在一起直到他们可以进入，然后帮助他们更改密码。计算成本时，您需要考虑这一点。

我的工作：

当我发现错误或安全性问题时，我将其记录下来，并估算要修复的开发成本。然后，我将其添加到列表中，并让合适的人知道。它可能永远不会从该列表中删除，但我每年（或每6个月一次）与网站所有者一起查看该列表，并尽我所能解决问题。

有了这种风险，它可能不会很快解决。我可以看到很多业务需求首先出现，这没关系。但是至少它是有文件记录的，当有人告诉我他们想在网站的那部分放置“秘密”信息时，我可以告诉他们有关风险的信息。

注意这种类型也很重要风险可能会导致其他类型的风险。编码时，做出了错误的安全决策。应该检查该站点是否有其他错误的决定。

#7 楼

请记住，作为开发人员，您可能比用户更了解实际的安全风险。如果用户发现其帐户被劫持，则他们可能会认为未经授权的用户可能会访问比其实际能力更多的信息。即使实际上没有暴露任何敏感信息，您的公司也可能会受到声誉打击。

还要考虑以下事实：您可能不知道哪些信息无害可泄漏。例如，如果用户有一个竞争性公司试图找出的新的革命性制造过程，该怎么办？如果需要维修新流程中使用的特殊设备并更改其电子邮件，则维修订单可能使另一家公司了解其新流程是什么。简单修复，最终您将必须进行评估，以查看风险是否值得修复它。

#8 楼

从客户（在某种程度上被视为受信任的客户）模拟合法用户是发起基于社交工程的攻击的好方法。

考虑到您控制电子邮件地址，因此修复表格->电子邮件处理非常适合此操作。也许您可以购买一个类似的域名并更改电子邮件地址“ someone@domain.com”->“ someone@domain.ca”，该地址与“我刚刚转移到我们的加拿大子公司，所以我没有我的我”记录，您能提醒我...吗？“

如果您可以了解有关客户/供应商历史的一些信息，则可以进一步向客户模仿供应商。通常这很简单，就像问“几个月前拜访的服务工程师叫什么名字？他们在特定问题上显然非常有帮助，但我不在了，我的同事也与他们打交道”。

#9 楼

不会，如果用户访问该站点，他将能够使用他的昵称（机密数据）来访问某人的电子邮件，在某些国家，这足以迫使您通知所有用户某人能够穿透数据库并且发生了信息泄漏。这样既损害了信誉，也不利于提起诉讼。

因此，一般来说，安全漏洞是可以接受的，但是这可能不是可接受的安全漏洞。同样，这种对您的用户所拥有的各种垃圾邮件的开放可能突然开始通过电子邮件接收恶意软件和垃圾邮件。

黑客总是乐于助人（利用他们）发现​​的缺陷。您假设用户身份不是关键信息，但如果是例如作弊网站，则可能是关键信息。另外，如果一个用户正在积极宣传某个教派/邪教怎么办，而突然间邪教成员可以发现自己的身份怎么办？如果泄露了缠扰者的某人并由于缠扰者能够再次找到他该怎么办？

在没有警告用户的情况下泄露身份会侵犯隐私，因此要当心。发现缺陷后应立即修复并进行风险分析。

例如，我希望删除所有论坛帖子而不是允许某人访问我的电子邮件地址。

#10 楼

这取决于极端情况。

情况A-不用担心！用您的话来说，对于可用数据并没有太大的担忧。如果它可能已经公开，并且整个安全设置只是一种营销/忠诚度计划，那么就没有太多需要在意的了。如果它是由没有专门知识的人完成的，那么它也可以解释草率的程序。只要该人能正常完成工作，就可以了。

方案B-担心！如果这仅是组织中某些部分情况的提示，则可能会发现更糟糕的安全漏洞。如果服务器对于企业至关重要，请首先考虑检查是否已正确备份，然后开始全面审核。

然后当然还有其余的字母。