检测 SQL 注入

Posted 2023-05-08

【中文标题】检测 SQL 注入

【英文标题】：Detect SQL Injection

【发布时间】：2010-09-21 20:14:47

【问题描述】：

我来到一家已经有一个成熟项目的公司......但是在我之前在这里工作的编码人员没有遵循惯例，也没有使用参数化的 SQL 查询......因此有超过 1000 个地方一个非常庞大的项目，可能容易受到 SQL 注入的攻击......

我需要找到一个能够自动检测代码中是否存在 SQL 注入的解决方案。因此，例如，有一个表单允许用户输入有关产品的 cmets，该表单将在提交时发送到数据库......我们如何确保用户没有输入有害查询而不是普通文本？

是否有任何高级代码/正则表达式/魔术可以检测此文本是否包含一段 SQL 查询而不是正常的无害文本？我会接受任何链接、任何语言的代码片段，甚至可以为我做这些的商业软件。

谢谢

【问题讨论】：

项目是用什么写的？

代码用VB.Net编写

如果您有 1000 个可能存在问题的地方，那么值得寻找自动化方法来编辑代码以使用参数化查询。

简短回答：将它们全部更改为准备好的语句。尝试任何其他方式几乎肯定会失败。此外，这是一个骗局。

很抱歉，您正在寻找失败。 “我的腿断了，明天我需要跑马拉松”这基本上是你在告诉我们的。您将不得不清理所有输入，这意味着要访问每一行 SQL 代码。无论如何，如果你在那里，把它变成一个准备好的陈述应该太难了。

【参考方案1】：

这里没有灵丹妙药。 SQL 注入可能以许多模糊的形式出现，并尝试使用正则表达式或防火墙中的其他形式来检测它们，或者应用程序可以保护您免受最简单形式的 SQL 注入，但有经验的黑客会轻松通过。正如 AdaTheDev 已经指出的那样，检查您的代码的自动化工具，例如 MS 代码分析工具，可能会给您一个启动，但同样没有灵丹妙药。您需要检查整个应用程序。

当工作量很大时，你应该制定一个计划。首先，制定一个指南，说明如何减轻这些类型的攻击。还要尝试将您的应用程序分成几部分，从非常关键到不太关键。通过这种方式，您可以更好地估算修复错误的成本，并让管理层决定可能的成本以及他们愿意承担的风险。未经身份验证的用户可以访问的应用程序部分是最关键的。如果每个人（世界上）都可以在您的应用程序中创建一个帐户，那么这些用户可以访问的所有功能都非常关键。人口越少，您越信任这些用户，风险就越小。您也许可以稍后修复这些部件。但永远不要低估一个优秀的黑客。他/她可能会破坏具有高权限的用户的帐户，并开始使用该帐户测试 SQL 注入的可能性。

始终尝试制定纵深防御策略，拥有多层（或多层）防御。例如，永远不要在应用程序中将数据库作为 SA 连接。创建一个仅具有所需权限的帐户，甚至可能创建多个 SQL 帐户，每个角色（或每个角色组）一个帐户。虽然限制对数据库的权限有助于降低风险，但同样，不要将其视为单层防御。例如，This article 解释了黑客在能够进行 SQL 注入时如何滥用较低权限的帐户。

很佩服你在这里问这个问题，因为我过去看到很多开发人员只是不想知道，这很可怕，因为企业经常信任它的开发人员（这也很可怕） )。

祝你好运。

【参考方案2】：

为了真正做到这一点，您只需划分应用程序并一次通过一个模块/页面/类/任何内容。

这不仅可以让您解决问题，还可以让您更加熟悉代码库。

更新 根据评论，我想再补充一件事：

工具唯一能做的就是说看，这里有一些未经处理的输入...很可能是应用中的每个查询。这意味着您将拥有大约 3000 个需要修复的文件的列表。

此时您唯一能做的就是指定一天（例如星期五）作为 Fix Sql Day。分工，然后让每个人花一天（甚至几个小时）在几页上重写查询。

在某些时候，您要么完成，要么发现足够多的其他错误来确定重新开始是否是个好主意。

【讨论】：

当有 1-300 个文件时这是一个好主意......因为我们有超过 3000 个文件，其中一半可能包含写得不好的 SQL......不幸的是，这需要一个多月的时间解决所有问题......我们口袋里没有那么多时间了。

【参考方案3】：

您可以试一试MS Code Analysis Tool（引用）：

CAT.NET 是一个二进制代码分析工具 这有助于识别常见的变体 某些普遍存在的漏洞 可以引起共同攻击 跨站点脚本等向量 (XSS)、SQL 注入和 XPath 注射。

我自己从未使用过，但可能值得一试。

【参考方案4】：

我赞赏您愿意潜入并解决问题，而不仅仅是耸耸肩说：“嗯……反正没有人会攻击我们的网站”。

我认为最好的方法可能是全面清理输入，假设它们是无辜的。问题是，有人可能有正当理由输入任何可能触发 SQL 注入的字符。

仅仅试图检测此类模式将受到误报“攻击”结果的影响；也许有人试图搜索john's car，根本不知道单引号可能是“坏的”。也许他们真的需要寻找那个。或者，你有什么……

【讨论】：

我同意。在安装警报之前开始查看这些窗口！

【参考方案5】：

您需要检查变量传入 SQL 字符串的位置。对于字符串值，您必须用双引号替换单引号的每个实例。对于非字符串值（那些将传递给不带引号的 SQL），您必须确保它们是强类型的。

例如不要传递"SELECT * FROM Users WHERE UserID = " + my_string_user_id 之类的东西。相反，请使用代码"SELECT * FROM Users WHERE UserID = " + userId_as_int。

当我有一个类似的代码库，根本没有参数化查询时，这可以追溯到。

【讨论】：

更糟糕的是在'sa'下运行SQL访问（连接字符串用户）。