security - 如何通过“测试驱动开发”确保安全编码？

Question

我一直在跟上最新趋势，即测试驱动开发(TDD)。我所做的大部分开发工作都是使用C或C++。令我惊讶的是，常见的TDD惯例和常见的安全编码惯例之间存在非常明显的冲突。从本质上讲，TDD告诉您不应为未通过测试的东西编写新代码。对我来说，这意味着我不应该编写安全代码，除非进行单元测试以查看我的代码是否安全。

这带来了两个问题:

如何有效编写单元测试以测试缓冲区溢出，堆栈溢出，堆溢出，数组索引错误，格式字符串错误，ANSI vs Unicode vs MBCS字符串大小不匹配，安全字符串处理(摘自Howard和LeBlanc的“编写安全代码”) ”)？

在标准TDD实现中的什么时候应该包含这些测试，因为许多安全性是不起作用的。

令人惊讶的是，我发现很少有关于TDD和安全性的研究。我遇到的大多数都是TDD论文，这些论文在很高的层次上提到TDD将“使您的代码更安全”。

我正在寻找上述问题的任何直接答案，与此相关的任何研究(我已经看过但没有发现太多东西)，或TDD大师居住的任何地方，以便我可以(实际上)敲开他们的门，看看他们是否有好的答案。

谢谢!

编辑:

出现了Fuzzing的主题，我认为这是解决此问题的好方法(通常)。这就提出了一个问题:模糊测试是否适合TDD？在TDD流程中哪里适合进行模糊测试？

参数化的单元测试(可能是自动化的)也让我无所适从。这可能是在测试过程中较早获得类似测试结果的方法。我也不确定确切地适合TDD。

编辑2:

谢谢大家到目前为止的回答。在这一点上，我对如何利用参数化测试充当函数的伪模糊测试非常感兴趣。但是，我们如何确定编写哪些测试来测试安全性？以及我们如何确保足够覆盖攻击空间？

软件安全性中的一个众所周知的问题是，如果您防御5种攻击情况，攻击者将只寻找并使用第六次攻击。这是一个非常困难的猫捉老鼠游戏。 TDD对此有何好处？

Answer 1

是的，TDD是一种可以帮助确保安全编码的工具/技术。

但是，与该行业中的所有事物一样:假设这是万灵药，那么您将被打死。

未知威胁

如编辑2所示:“您可以防御5种攻击情形，攻击者只会寻找并使用第六次攻击”。 TDD是，而不是，可以保护您免受未知威胁的侵害。就其本质而言，您必须知道要测试的内容才能首先编写测试。

因此，假设发现了6号威胁(希望不是由于破坏，而是内部是由于尝试查找潜在攻击媒介的另一种工具/技术)。

TDD将提供以下帮助:

可以编写测试来验证威胁。

可以实现一种解决方案来阻止威胁，并迅速确定其正在起作用。

更重要的是，如果所有其他测试仍通过，则可以快速验证:

所有其他安全措施仍然可以正常运行。

所有其他功能仍然正常运行。

基本上，TDD可以帮助您从发现威胁到解决方案可用之间提供快速的周转时间。

TDD还为新版本的正常运行提供了高度的信心。

可测试的代码

我读到，TDD通常被误解为测试方法论，而实际上它更像是一种设计方法论。 TDD改进了代码的设计，使其更具可测试性。

专业测试

测试用例的一个重要特征是它们运行时没有副作用的能力。意味着您可以按任何顺序，任何次数运行测试，并且它们永远不会失败。
结果，纯粹由于可测试性的结果，系统的许多其他方面变得更易于测试。例如:性能，内存利用率。

通常通过对整个测试套件进行特殊检查的方式来实现此测试，而不会直接影响套件本身。

类似的安全测试模块可以覆盖测试套件，并寻找已知的安全问题，例如内存中保留的安全数据，缓冲区超限或任何已知的新攻击媒介。这样的覆盖图将具有一定的置信度，因为已经检查了系统的所有已知功能。

改良设计

作为TDD的副作用而产生的关键设计改进之一是显式依赖。许多系统承受着隐式或派生依赖性的影响。这些将使测试几乎不可能。结果，TDD设计在正确的地方倾向于更加模块化。从安全 Angular 来看，这使您可以执行以下操作:

测试组件，这些组件无需实际通过网络发送即可接收网络数据。

一个人可以很容易地模拟出对象，使其以意外/“不现实”的方式表现出来，就像在攻击场景中可能发生的那样。

隔离测试组件。

或与生产组件的任何所需组合。

单元测试

应该注意的一件事是，TDD支持高度本地化(单元测试)。结果，您可以轻松地测试以下内容:

SecureZeroMemory()可以从RAM中正确删除密码。

或GetSafeSQLParam()可以正确防止SQL注入(inject)。

但是，要验证所有开发人员是否在所需的每个地方都使用了正确的方法就变得更加困难。
验证新的与SQL相关的功能的测试将确认该功能正常工作-它与GetSQLParam的“安全”和“不安全”版本同样适用。

出于这个原因，您不应忽略可用于“确保安全编码”的其他工具/技术。

编码标准

代码评论

测试