问人对易损扫描器

EN

大多数访问控制/授权缺陷永远不会被(泛型)工具发现，因为它不了解什么是可以访问的，什么是不可以访问的。(话虽如此，经验丰富的戊酯可能知道，许多应用程序也没有这种记录.)这就是整个问题的一个例子。

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

任何一系列漏洞都不会相关，例如，如何使用低风险信息泄漏，以及一个中等风险的DOM XSS，以及另一个低风险漏洞，以便将用户的密码更改为攻击者想要的任何内容(这是我看到的一个实际示例)。

像大多数商业工具一样，用普通的(通常)扫描仪测试DOM是相当困难的，因为它们没有Javascript运行时，所以它们会错过其中的大部分。

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

或者考虑一下DoS。自动化工具是如何发现的呢？

最后一个例子是，上传和处理的文件中的缓冲区溢出如何处理，比如用户上传的图像被服务器端库调整大小，易受bof攻击。自动化工具如何知道这种情况，以及如何为其创建一个漏洞？

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

总之,

• 在一般情况下，无法测试的漏洞有整类。
• 即使对于自动可测试的漏洞，编写全面的测试(一组查找漏洞所有实例的测试)也是不可能的。

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

我只想补充上面的答案，像SQL注入和XSS这样的漏洞可以被系统的进程(并不总是)检测到，一个工具就足以完成这项工作，但是正如@lengyelg说的那样，有一些复杂的情况是无法被工具容易检测到的，例如:盲SQL注入，在order by或limit之后注入，应用程序在WAF之后，应用程序的响应是JSON数据结构；这种漏洞需要时间来分析，如果您运行一个工具，它可能无法检测到漏洞，我不想说工具无法检测到它们，但是工具需要正确配置知识。获得这些知识的最好方法是自己动手，知道应用程序、正确的响应、不正确的响应、应用程序的错误等等；当您能够很好地理解应用程序及其每个组件的行为时，您就可以构建一个很好的开发和配置工具，以便更快、更高效地完成工作。工具可以帮助我们完成我们的工作，但在我的作品中，它永远不应该完全完成我们的工作。然后，我认为工具需要人类的知识，锤子需要正确的力量和正确的方向来做好工作。