我们有一组内部 Python/Django Web 应用程序，这些应用程序在功能方面经过了很好的测试，但我们不时会发现漏洞，特别是可能发生 SQL 和其他类型注入的地方。目前，这是一个非常手动的过程，需要系统知识（白盒）。
但是，有没有办法对我们被测应用程序的所有 API 端点进行自动化 SQL 注入测试？
我想我现在不明白的一些事情是：我们是否应该真正为它们编写这些测试和示例的逻辑并使用 Pythonunittest框架，或者有没有办法指定端点和可能的参数并让一些安全性测试框架生成格式错误的输入来探测 SQL 注入（sqlmap？）（问题在某种意义上是关于它是基于示例的测试还是基于属性的测试）
您可以很容易地编写基于示例的测试脚本。通过一个示例请求，sqlmap 可以完成剩下的工作。我认为默认情况下它唯一不做的是路径参数，但这也可以合并到您的脚本中。这样做的问题是它将成倍地增加单元测试运行所需的时间，因此通常不会以这种方式完成。由您和您的开发人员决定是否可以接受添加的时间。根据我的经验，一般不会。您还可以构建一些在单独的线程中启动 sql map 的东西，例如，当某些东西被部署到阶段时，如果发现某些东西，就会提醒安全性。这样它就不会阻止你的构建。不过，基于示例的测试将是您问题的答案。
我想从不同的角度来看待这个问题。
您说过您在应用程序的不同 API 端点中发现了许多 SQLI。
针对此类问题的修复/缓解措施究竟是什么？即使在此修复之后，又怎么可能在同一应用程序的另一个端点中发现另一个问题？
应用程序的结构究竟如何？
我的想法是像隧道一样构建所有 API 请求首先通过的隧道，然后根据字符白名单检查字符串是否为 ex。我相信有些图书馆也可以做得很好。
现在大多数 ORM 都在为你做这项工作。
也许了解应用程序中的数据访问层是如何构建的并尝试重构它并遵循OWASP备忘单来缓解 SQLis 也会很有趣。
我并不是建议忽略自动化测试部分。我很好奇为什么这个问题在修复了很多次后仍然存在。
也不可能说您可以完全消除此类问题，这就是为什么即使在为整个应用程序找到通用解决方案之后，您仍可能需要这些自动化测试。
有趣的问题！
您需要自动化多个流程才能使其正常工作。没有神奇的产品（我知道）可以做到这一点，但这里有一个算法：
收集有关运行 SQL 应用程序的 Web 服务器的信息。这可以通过以下方式轻松完成nmap -sS host-range -oX output.xml -p 80,443,8080,1080
在这些找到的应用程序中，从 output.xml 文件中收集 POST/GET 参数以对它们进行测试。这可以通过 curl 和一些 bash 脚本，或python借助 or 的 XML 解析器curl来完成wget。
使用收集到的 POST/GET 参数请求列表来提供给SQLMapSQL 注入测试。像这样的东西：
对于列表中的每个 POST/REQUEST { 执行 SQLMap -u link_from_list --risk 3 --level 3 如果标记为 SQL 注入 { report() } }
调查报告；消除误报并最终确定开发团队修补的报告
补丁，补丁，补丁！
从步骤重新开始 [1]