首先是一些背景：
我是一名基础架构工程师，拥有 5 年主要在虚拟化和网络方面的经验。
在过去的一年里，我做了很多关于安全性的自学，通过了 Security+，阅读了 Web 应用程序黑客手册，并通过使用 Bugcrowd 和 Hackerone 发现错误赚了一些钱。
每当我寻找漏洞时，我总是跳过 SQL 注入，因为大多数现代应用程序与书籍或在线教程中显示的传统 SQL 注入方法相比没有任何明显的弱点。
现在，其他安全爱好者也是如此吗？你如何处理这个问题？我尝试发送很多不寻常的字符，但到目前为止我得到的最好结果是错误 500。
提前致谢
实际上，根据 OWASP，SQL 注入是通过 Web 应用程序的十大漏洞之首。 https://www.owasp.org/index.php/Top_10_2013-Top_10
并且有很多关于这个主题的论文、文章、新闻，而且每天都有关于 SQL 注入攻击著名 Web 应用程序（例如 Joomla、Wordpress 或网站等）的新闻，所以我们不能说“现代应用程序对传统的 SQL 注入方法没有任何明显的弱点”，因为每天都会引入一种新的 SQL 注入方法。
SQL 注入绝对不是我在测试安全性时会跳过的事情。根据Ponemon Institute 违规报告，SQL 注入占恶意或犯罪违规的 30%，是导致违规的所有攻击媒介中最多的。
我的公司使用多种方法来查找我们专有应用程序中的 SQL 注入漏洞。我们在开发、测试和生产中使用通过静态代码分析和渗透测试扫描源代码的组合。这与入侵检测系统 (IDS) 和 Web 应用程序防火墙 (WAF) 等技术控制相结合。
静态代码分析厂商/产品：
一些进行渗透测试的供应商/技术：
您可以在此处查看多种检测和/或阻止 SQL 注入的方法： Imperva - 如何阻止 SQL 注入。虽然阻止可能不是您想要的，但它肯定有一些很好的工具来确定它是否容易受到攻击。
最简单的方法是运行一些简单的脚本，在网站上抛出垃圾/攻击，但显然我会先清除它。
我不确定现代应用程序到底是什么意思。是的，许多框架、ORM、实体框架等分解查询并可能应用一些默认过滤。但是，在需要自定义编码的更复杂的场景中，或者 ORM 或库函数不能完全按照您的要求执行时，您将打开 SQL 注入或其他攻击的大门。
有了很多 ORM 和框架，安全部分就已经融入其中。这会产生自动处理一些安全问题的影响，但同时，许多开发人员可能不了解这些库函数为他们做了什么，以及何时使用需要制定一个定制的解决方案，他们只是遵循一些教程，不知道他们需要考虑安全性。
此外，当您离开基本的最终用户 CRUD 类型的应用程序时，开发人员可能需要使用维护得不太好的库。例如，假设您有一个业务应用程序，有人可以在其中上传CSV文件并且正在处理该文件。也许有人写了一个库来处理这个问题并且没有使用 ORM，它可以工作，所以你的开发人员可以使用它。然后逐行读取 CSV 并处理到数据库中，这里可能会进行 SQL 注入。
SQL 注入是缺乏正确输入验证的症状，在不太常见或更复杂的场景中，这种情况的可能性会增加，因为这些场景不能被烘焙或事后考虑。
此外，“现代”应用程序可能看起来很现代，但建立在一些旧的垃圾或一些奇怪的遗留连接之上，这些连接会摆脱人们的期望。
OWASP提供了一些关于如何解决 SQL inhections 的信息，如不存在。最近的Drupal SQL 注入表明这根本不是真的（即使在像 Drupal 这样成熟的环境中也是如此。）
你找到这些东西的方法通常是简单地使用模糊器并将随机垃圾发送到 Web 应用程序。