是否值得在每个应用程序中降低安全风险

Question

作为Web开发人员，我们的应用程序容易受到许多安全漏洞的影响（xss， SQL-内喷射，等...）。我坚信，如果你正在编写应用程序应该是 免受所有这些众所周知的漏洞的影响。但是，我很难过 说服我的团队（和管理层）认为这是值得的。

这让我想知道应该在什么条件下打一场安全战呢？什么 是决定安全漏洞时应考虑的因素  缓解和忽略哪些？

Answer 1

贵公司应该制定隐私和数据保护政策，无论您是在烘焙面包还是开发网络应用程序，这应该构成您的方法的基础。

就个人而言，我的工作基于“可能发生的最糟糕的事情是什么？”，并采取相应的行动。如果“最差”是您的内部网站被恶意内部用户删除，那么这可能是一个值得生存的风险。如果“最差”是您的客户未加密的财务详细信息被公开，那么......

Answer 2

当然你应该解决安全问题。这应该是一个较低优先级的唯一原因是，如果你“信任”软件的用户（例如，没有任何接受用户输入是面向公众的），但它仍然需要完成，因为人们可以意外地利用一些安全漏洞

Answer 3

完整的安全性分析不仅可以分析威胁，还可以分析威胁。我们来看一个示例，SQL注入。如果您的数据库访问权限只能读取但从不写入数据库怎么办？现在，SQL注入不会损害您的数据库。但是，您仍然遇到可以操纵SELECT查询以获得更多所需结果的问题。那是问题吗？可能是的，但这是一个不同的问题需要解决，因为你可能会以某种方式过滤输出数据。

这不是一个很好的例子，它应该如何完成，但它是由于时间和预算限制有时不幸地必须完成的一个例子。基本上：查看所有威胁，找到那些真正搞乱的东西，然后消除它们。

另一个例子：在Stackoverflow上，我想我能够在这个答案框中插入任意HTML，比如输入框或者可能是一些JavaScript，但除了我之外没有人会看到文本框。服务器将它删除，我无法伪造一个链接，填充其他用户的答案框。简而言之：我只能把自己射到脚下，所以这不是杰夫应该关注的安全问题。

Answer 4

不幸的是，我认为答案是在每个应用程序中都不值得。这就是我们普遍存在糟糕安全的原因。看一下安全专家Bruce Schneier said on this。{/ p>

Answer 5

不要缓解漏洞，修复它们。

如果你有一个SQL注入，那是因为你的数据库访问层是错误的。采用缓解策略，例如使用'SELECT'或'等关键字过滤掉参数; DROP DATABASE'做错了。而是转向数据库访问方法，该方法以适当的方式为所涉及的数据库自动转义传入参数。然后，您不仅可以解决问题，还可以确保应用程序在遇到“O'Reilly”或其他问题数据时正常工作。

如果你有一个HTML注入导致XSS，你的模板策略鼓励你盲目输出未转义的文本。不要试图通过检测和拒绝'＆lt;'来缓解这种情况。在数据中，你会遗漏一些字段而你不知道所有特殊情况，更不用说有人可能有正当理由输入'＆lt;'。而是通过更改您的模板系统或样式来修复它，以便在您输出文本的任何时候，即使数据“不能”包含特殊字符，您也总是将其HTML格式化，即使数据“不能”包含特殊字符。

至于您可以忽略哪些安全问题，这取决于您的业务以及客户依赖它的程度。通常，有四个级别的折衷影响Web应用程序（我假设你在提到SQL注入和XSS时正在讨论）：

1. 服务器级别的妥协。通常来自受到严重保护的shell和FTP帐户，但也会升级应用程序级别的妥协。运行带有用户提供的数据的系统（）的应用程序经常会受到严重影响，以及SQL注入，其中数据库是配置不当的SQL Server（使用xp_cmdshell）。攻击者可以在服务器上获得shell访问权限，并且可以愉快地在其他服务器上发送大量垃圾邮件和黑客攻击。这对任何企业都是不可接受的。

2. 应用程序级别的妥协。通常是SQL注入。攻击者可以从数据库中读取或删除任何客户信息，否则会干扰应用程序的运行。如果它几乎是一个玩具应用程序，并且您的客户将接受他们的数据死亡，或者如果关闭应用程序的访问权限，只有选定的可信方/客户可以使用，这是可以接受的。

3. 数据级别的妥协。通常HTML注入XSS。攻击者可以在您的网站上放置一个iframe，指向浏览器安全漏洞，将恶意软件置于使用过时软件查看该页面的人的计算机上。如果您没有提供关于客户安全性的图，或者，如果应用程序关闭以进行一般访问，那么这是可以接受的。

4. 用户级别的妥协。通常未经验证的行动表格会导致跨站点请求伪造攻击。如果您的应用程序不太可能让攻击者无法尝试此操作，则可以接受。

一般来说，行业目前处于3级左右。启用1级攻击的应用程序现在很少见; 2级漏洞更常见，但大多数作者都知道并且知道它们应该修复的问题。 3级漏洞很常见，并且没有广泛遵循避免所有可能的HTML注入的策略。 4级漏洞可能会影响到今天的大多数网络应用程序。

Answer 6

这始终是一个非常棘手的问题。我会说这取决于网站的可访问性。如果它将拥有广泛的受众，最好保护所有标准项目--xss，sql注入等。除此之外，应该认真看看可以用最低成本锁定其他方法。如果一个站点的流量很低而且访问量很小，那么除非它们是敏感信息，否则我不会太担心。

这取决于。如果你认真考虑安全将是一个问题，那么选择你知道将用于攻击的东西，并建立防御它 - 如果需要的话，在工作之外。然后监视站点是否存在安全攻击。当发生攻击时，报告它并声明损坏被阻止，因为你主动做了一些事情。再补充一下这可能发生的事情 - 可能在告诉任何人攻击被阻止之前说出来。如果你认为这不值得花时间，那么它可能不值得做，你可能希望老板和团队能够生活和学习。当众所周知的便便击中粉丝时，让它掉下来并帮助解决问题。

Answer 7

正确地，应该对任何安全编程工作进行风险/回报估计。但是，在计算机安全性（机密性，完整性和可用性）的三个主要方面，您实际上只是在考虑机密性。也就是说，防止未经授权的用户访问。

如果您包含数据完整性和系统可用性，您会发现大多数安全性编程工作的回报远远大于机密性。适当的安全设计还会捕获大量非恶意错误，从而提高应用程序的正常运行时间和数据完整性。

停机时间的成本是多少，不一定是因为攻击者？提交错误数据的声誉成本是多少，这些数据很容易被检测为坏？将其添加到计算中，并且几乎在所有情况下遵循安全编程实践都是值得的。安全预防措施应该不被认为是额外的努力，但应该成为每个应用程序设计和实现的一部分。如果你这样做，额外的努力就会变得非常小，而且就更可靠的操作和应用程序信任而言，回报非常大。

Answer 8

务实的方法是进行适当的输入验证，并在www情况下 - 正确的输出转义。

对于您获得的每个变量，应用最严格的过滤规则： 如果你得到一个页面的id，那么is_integer（myvariable）＆amp;＆amp; myvariable＆gt; 0;是一个正确的检查。

安全流程是一个风险管理流程，遵循这些方针：

1）检查用例;

2）考虑适用的所有风险;

3）选择要消除的风险（通过安全编码或其他方式），通过补偿控制（例如对起诉或用户政策的威胁）以及接受哪些风险（因为它们如此偏远或过于昂贵）可以减轻风险反击）。不要忘记监控这些风险。

因此，并列上面两段，我们得出的结论是，编写Web请求处理程序的程序员应始终了解可能存在的风险，并决定消除/减轻/接受它们。由于程序员手上的时间有限，他应该应用法西斯输入验证，不要依赖数据源来清理数据，因为他可能不是唯一使用相同数据库的人。

另一方面，如果您只想到OWASP Top Ten，那么您已经完成了尽职调查。