程序猿补上信息安全的漏洞_解决应用程序安全漏洞

程序猿补上信息安全的漏洞

解决应用程序安全漏洞要比实际困难得多。

WhiteHat Security在其2013年5月的安全 告中 ，发布了一些令人沮丧的发现，这些问题涉及在测试中发现多少个应用程序安全漏洞得到修复，以及修复这些漏洞需要花费多长时间。 他们发现，只有61％的严重安全漏洞得到修复，而平均而言，修复这些漏洞需要193天。

为什么某些漏洞得以修复或未得到修复

说服管理人员和为软件开发工作付费的客户以及需要执行该工作的开发人员，确实需要修复安全漏洞是问题的一部分。 证明可以成本有效且安全的方式完成此操作是另一回事。

对于大多数组织而言，合规性（不是运营风险，客户需求或其他商业考虑，也不是质量问题）决定了安全漏洞是否得到修复。 WhiteHat客户 告说，修复漏洞的第一大原因是合规性要求。 人们不修复漏洞的第一个原因是合规性不是必需的。

影响系统修复了多少个安全漏洞以及修复这些漏洞的速度的其他因素之一是系统的生命周期。 在您编写许多需要再次检查，修复和测试的代码之前，修复项目早期发现的安全漏洞要容易得多，花费也少得多。 当情况和系统都具有足够的可塑性时，您可以进行路线校正，而无需花费大量时间或金钱。

显然，对于生命支持的遗留系统而言，这是完全不同的故事，没有人真正理解该代码或没有信心可以安全地对其进行更改，也没有人知道该系统将使用多长时间（尽管这些系统几乎总是挂着比任何人期望的时间更长）。

介于两者之间的一切都是难以做出决定的地方：该系统已经在使用中并且已经使用了一段时间，并且维护和支持该系统的团队拥有一整套致力于工作的书。 当事情看起来一切正常时，很难将修复安全漏洞作为优先事项，并且每个人都在忙于以这种方式进行维护，除非合规性正站在您手里握着足够大的锤子以至于您必须做点事来展示你是认真对待他们的。

这要花多少钱h2>

如果可以确定存在严重的安全问题需要解决，那么从哪里开始呢全审查可能会发现数百甚至数千个漏洞–首次对大型系统进行安全扫描或笔测试可能会令人不知所措。 “确保系统安全”需要花费多少工作，这将花费多少/p>

Denim Group在了解了解解决安全漏洞方面涉及多少工作方面进行了一些有趣的研究。

与其他任何代码错误一样，某些漏洞比其他漏洞更容易找到和修复。 一个XSS漏洞可能需要10分钟（存储的XSS）到大约一个半小时（存储并反映）的任何位置修复-大多数Web应用程序至少有一个（通常是数百个）问题。 修复SQL注入问题平均还需要一个半小时。 缺少授权检查有7分钟。 与其他代码错误一样，编码工作仅占完成修复所花费时间的一小部分（平均占总时间的30％）。 测试花费了大约一半的时间，其余的时间是进行设置以进行更改，构建和部署新代码以及开销。

与功能性错误不同，客户在修复漏洞方面不会立即看到任何优势-该代码现在可以正常运行。 因此，很重要的一点是，您无需花费太多时间或金钱就可以修复漏洞，并且可以在不破坏任何已有工作的情况下做到这一点。

这就是为什么尼克·加尔布雷斯（Nick Galbreath）强调持续部署功能的价值，这是成功的软件安全程序的前提条件 ，它利用持续集成和持续交付工具和实践来确保开发人员在检入代码更改时自动构建，测试和开发系统。如果所有测试通过，它可以自动部署。 这并不是要立即推送每个代码更改，而是要有一个成熟的管道来确保将更改快速发布到生产环境中并且风险最小，知道您可以进行修复并以低廉的价格自信地发布它们，并且您有能力必要时应对紧急情况。 这将使安全工作以外的其他方面受益匪浅，从而降低了成本和进行任何软件更改的风险。

修复安全漏洞

Denim Group解释说，必须像其他任何软件开发项目一样管理补救软件安全漏洞，并且他们提供了有关如何以瀑布式方式进行操作的准则 ，并需要利益相关者的预先参与和计划：这种方法可以很好地解决问题。许多组织，尤其是大型组织。

更具迭代性的敏捷方法可以从短暂的带时间限制的峰值开始。 挑选几个聪明的开发人员，并给他们几个星期的时间来审查漏洞列表（如果可能，与发??现它们的人一起），了解哪些漏洞很严重并过滤掉误 ，然后选择一些漏洞进行修复（每一个漏洞不同类型的）。 他们应该通过权衡容易理解和解决的漏洞来选择要解决的漏洞，以免得不到解决的风险 。 诸如OWASP Top 10或SANS / CWE Top 25之类的工具可以帮助您理解问题并做出决策。

SQL注入将是一个不错的第一选择：一个严重的漏洞，易于利用，可能会导致严重的后果，但也使开发人员易于理解和修复 。 或错过了授权检查 ：另一个潜在的严重错误，应该易于理解，难以修复和测试。 安全密码存储中的错误之类的问题在技术上可能更难解决，但仍易于隔离和测试。 添加服务器端验证（而不是仅在客户端进行验证）是另一个容易且不错的起点。

开发人员花时间了解他们在做什么以及如何正确执行它很重要：他们了解漏洞，为什么会成为问题，如何正确修复它以及如何对其进行测试（对其进行测试）确保他们确实关闭了安全漏洞，然后对其进行回归测试以确保它们不会意外破坏其他任何东西）。 这里重要的不是进行一些修复，而是要了解正确解决这些问题所涉及的内容，并知道您可以正确地构建和部署固定的代码。

然后运行另一个峰值。 选择一些其他的bug，也许是一些较难理解和修复的bug，以及一些易于修复但不太严重的bug（例如缺少错误处理或信息泄漏），然后再次执行相同的步骤。

只需花费很少的时间，您就应该了解需要完成的工作，如何做，将要花多少钱，并且还应该有信心可以安全地完成工作。 您应该有足够的信息来估计解决剩余问题所需的工作量； 并且对需要进行的风险和成本权衡有足够的了解，哪些问题迟早需要解决，并且可以解决。

现在，您可以将计划修复的其余错误添加到积压中。 您可能决定在一次强化sprint中一次修复尽可能多的问题，或者与积压的其他工作一起对它们进行优先排序和修复。

在您了解安全漏洞之前，您无法修复或有效地计划对其进行修复。 一旦了解了问题（错误是什么，需要修复的问题以及原因）以及修复这些问题的费用，并且一旦确信可以正确修复它们，就可以处理安全漏洞。像其他错误一样，通过需要与其他工作权衡的成本和风险来决定需要解决的问题以及何时修复。 补救工作只是要管理的另一个软件开发问题，开发人员和管理人员已经知道该怎么做。

参考： 获取我们的JCG合作伙伴 Jim Bird在Building Real Software博客上修复的应用程序安全漏洞 。

翻译自: https://www.javacodegeeks.com/2013/08/getting-application-security-vulnerabilities-fixed.html

程序猿补上信息安全的漏洞

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览93918 人正在系统学习中 相关资源：板式家具数控开料机补板/补单软件–支持导出NC代码_NC代码-智能…