（通用）工具永远不会发现大多数访问控制/授权缺陷，因为它不了解什么应该是可访问的，什么是不可访问的。（话虽如此，有经验的渗透测试者可能知道相当多的应用程序也没有这个文档......）所以这是一整类问题的一个例子。

任何逻辑缺陷（例如，用户能够通过设计创建另一个具有更多权限的用户）也不会被自动化工具检测到。

任何漏洞链都不会关联，例如如何使用低风险信息泄漏、中等风险 DOM XSS 以及另一个低风险漏洞将用户密码更改为攻击者想要的任何内容（这是一个实际示例我见过）。

像大多数商业工具一样，使用普通（普通）扫描仪测试 DOM XSS 非常困难，因为它们没有 Javascript 运行时，所以他们会错过大部分内容。

同样对于可测试的东西，一个工具可能有几种模式可供尝试，但可能会错过更复杂的情况。例如，如果一个应用程序有一个针对 XSS 的黑名单过滤器，它明确阻止了 alert(1)，并且来自该工具的所有攻击向量都将其作为有效负载，该怎么办？通过黑名单过滤器几乎总是可能的，但对于自动化工具来说非常困难。

或者考虑 DoS。自动化工具如何找到它？

对于最后一个示例，上传和处理的文件中的缓冲区溢出怎么办，例如用户上传的图像由服务器端库调整大小，容易受到 bof 的影响。自动化工具怎么会知道是这种情况，以及它会如何为它创建一个漏洞利用呢？

这些只是一堆例子，我相信其他人会引用更多。

简而言之，

• 在一般情况下无法测试整类漏洞

• 即使对于可自动测试的漏洞，也几乎不可能编写全面的测试（一组找到漏洞所有实例的测试）。

当然，考虑到所有这些，我认为使用工具来更快地完成几件事并没有错。然而，任何来自工具的结果都需要由测试人员重现，而且他必须意识到该工具的局限性，以便能够通过更具创造性的攻击来增强结果。

我只是想补充上面的答案，系统进程可以检测到 SQL 注入和 XSS 等漏洞（并非总是如此），一个工具就足以完成这项工作，但正如@lengyelg 所说，有些复杂的情况是不可能的由工具轻松检测到，例如：注入可能在之后order by或之后的盲 SQL 注入limit，应用程序位于 WAF 后面，应用程序的响应是 JSON 数据结构；这种漏洞需要时间分析，如果你运行一个工具，它可能无法检测到漏洞，我不想说工具无法检测到它们，但是一个工具需要知识才能被发现正确配置。获得这些知识的最好方法是自己动手，了解应用程序、正确响应、错误响应、应用程序错误等；当您能够很好地了解应用程序及其每个组件的行为时，您就可以构建一个好的漏洞利用并配置一个工具来更快、更高效地完成工作。一个工具可以帮助我们完成我们的工作，但在我看来，它永远不应该完全完成我们的工作。然后我认为一个工具需要人类的知识，