我们应该构建一个通用的安全单元测试套件吗？
作为安全SDLC的一部分，我们将安全性作为安全需求直接交付到应用程序团队的待办事项中。安全需求将直接与迭代中交付的功能特性相关。我在这里主要讨论的是基于应用程序的控件(代码级别)。
作为其中的一部分，我们希望鼓励对这些需求进行单元测试，将其作为一种充分验证其实现的机制，并进一步促进TDD的实践--即开发人员将为安全性功能开发一个单元测试，例如路径遍历的输入验证，等等。
我已经读到，开发一个通用的单元测试套件对我们来说是个好主意。
现在我要问-是吗？
对我们来说，开发一组JUNIT测试来集成到开发团队项目中真的是个好主意吗？这里不存在灵活性的问题吗，因为我们基本上是标准化了开发团队的安全功能的方法、参数和命名吗？
也许还有另一种方法，我们可以开发通用单元测试，允许开发人员调用他们定制的方法，而不需要遵循我不知道的测试框架的方法签名？我想集成它的开销将是巨大的！
开发测试是否不违背TDD，因为开发人员不需要“考虑他正在交付什么并首先编写测试”？
我的直觉是，测试套件应该是针对每个需求的sudo代码，其中包含异常值以及开发人员必须实现的负面和积极的场景--这样，如果我们用C、C#或python等语言编写测试套件，那就无关紧要了。
这不是一个更好的方法吗？
回答 1
Security用户
发布于 2020-11-06 16:51:00
是的，我正在和我的团队进行同样的辩论，我对此同样感到矛盾。
安全单元测试的参数：
- 安全测试的可重用性/自动化(即您可以根据新产品/特性重用安全单元测试，而无需appsec团队进行手动测试)
- 回归测试:在将来继续测试这些安全缺陷，而不是实时手动测试.
反对安全单元测试的论据：
- pen测试通常依赖于安全测试人员的经验和培训，并且通常不依赖于对安全测试人员的经验和培训，而通常情况下，如果您只是坐下来定义积极和消极的测试用例，并且/或甚至不可能通过单元测试进行测试，那么pen测试通常不是你会想到的事情。笔测试用例通常也很复杂。例如，有人可能会编写一个junit测试，用于“进行登录流到但不包括MFA；取中间流JWT并尝试使用它调用API”。或者“为
sub=中的每个值为此XSS有效载荷列表创建一个JWT，然后在UI中导航并查看是否执行任何javascript有效负载”。事实上，我甚至不知道你在junit中是怎么做的。 - junit测试通常是测试单个方法。您可能会在那里发现真正的安全问题，但是高价值的安全问题通常发生在软件层的边界上；例如:您有一个GET控制器，它假定CSRF保护被应用于它，但是Spring只被配置为在POSTS上执行CSRF。或者tomcat正在监听/admin的reqs :666，防火墙最好在外部阻止它。(加上前面项目中的内容；代码的登录和访问控制部分之间的不匹配；JWT和UI之间的不匹配)。
我想我已经登陆的地方是，您的一些手工探索性appsec测试将是自动化的。比如，在Burp或ZAP会话结束时，回顾一下您的历史记录，找出一些很好的自动化候选程序，然后导出为curl，然后将它们放入单元测试中。太好了增值了。但是要认识到高价值的安全问题可能不会出现在单元测试中，所以询问这是否是appsec时间预算的最佳使用。
https://security.stackexchange.com/questions/240497
复制相似问题
腾讯云开发者
