SQL Server 和 SQL 注入答案

【问题标题】：SQL Server and SQL InjectionSQL Server 和 SQL 注入
【发布时间】：2021-06-06 09:45:32
【问题描述】：

SQL injection: isn't replace("'", "''") good enough?

我想知道用“''”替换“'”是否可以防止sql注入。我不喜欢它，但作为原始问题中的人，我继承了一个使用“坏习惯”的代码库。

我阅读了那篇文章，但不确定是否可以为 SQL Server 注入 sql（似乎有点争议的答案）。

所以我会问是否有人可以编写一个选择（以这种方式“转义”），这最终会再次失败 SQL 注入。如果不可能，我会认为它是安全的。

---编辑（添加了从真实代码推断的示例，名称是虚构的，由于 NDA 但结构相同）：

C#代码

string sql = $@"SELECT [FIELD1] ,[FIELD2], [FIELD3] 
                FROM [MY_TABLE]
                WHERE [FIELD1] = '{UtilityBase.ChkString.(field1, "'")}'";

这里使用的sql

using (System.Data.SqlClient.SqlDataAdapter xDtAdpt = new System.Data.SqlClient.SqlDataAdapter(StrSql, Conn))
{
    RSDataSet = new System.Data.DataSet();
    RSDataSet.EnforceConstraints = false;
    xDtAdpt.Fill(RSDataSet);
    RSDataSet.EnforceConstraints = true;
    xDtAdpt.Dispose();
}

检查字符串是：

public static string ChkString(object xString, string xSeparator = "")
{
    try
    {
        if (string.isNullOrEmpty(xString))
        {
            return "NULL";
        }
        else
        {
            return xSeparator + xString.ToString().Replace("'", "''") + xSeparator;
        }
    }
    catch
    {
        return "";
    }
}

【问题讨论】：

它会在一些处停止注入，而不是全部。例如，在注入动态对象时替换单引号 (') 不会阻止注入。如果你有参数，你应该参数化它们；这始终是最安全的方式。
使用 SQL 参数，有大量关于如何避免 SQL 注入的文章，而且很多都超级容易实现，尤其是从头开始时。
当用户输入是字符串时，我只会知道与用户输入一起使用是否安全。我知道这是不好的做法，我不喜欢它，但我无法请求如果存在具体的安全风险，软件重写（有成本）。所以我需要一个 POC 来要求重写该遗留代码。如果你能写出 POC 请回答我的问题，我很高兴接受它
除了与奇怪的 Unicode 转换有关的特定问题外，我想简单的答案是：风险是真实存在的，我们如何保证在任何地方都使用 Replace 以减轻这种风险？验证这一点的唯一方法是检查所有代码，此时同时参数化并没有太多工作量。
如果您对特定示例有疑问，请发布。您的 SQL 是如何执行的？您是否将参数连接到过程中的字符串中？您是否在代码中动态构建字符串并直接执行？请举例。

标签： c# sql-server escaping sql-injection

【解决方案1】：

您应该向您的老板推荐利用安全渗透测试公司的专业知识。无论如何，这是应该作为最佳实践定期执行的操作，我保证他们会发现许多您不知道的漏洞，包括一些狡猾的 sql 注入攻击。

相信我，不管你认为你的字符串清理有多好，根据经验，只有一种安全的方法可以将数据传递到数据库。

【讨论】：

【解决方案2】：

“我继承了一个使用“坏习惯”的代码库。”

这不是一个“坏”的做法。这是一种致命的做法。 SQL 注入仍然是排名第一的漏洞。

您必须花时间参数化您的 sql。否则，即使是脚本小子（新手黑客）也可以访问您的网站。或者，很可能，已经有了。

只是我的看法。我可能是错的。

【讨论】：

在那段日子里，我读了很多关于这个话题的文章。我怀疑 SQL 注入最后不可能用那种“坏”的做法。在我看来，这只是一种不好的做法，因为程序员需要非常小心地“清理”每个输入。所以我需要确定安全性，因此我提出了这个问题。我正在寻找的是一个注入示例（在我的场景中）或其他一些文档，这些文档清楚地表明这种方法是可行的。
@Skary。我不得不和一个喷火，脊椎骨折的保安人员一起生活。所以，我什至不考虑不使用参数化查询。我们在代码上安装了扫描程序，以寻找 sql 注入漏洞以及其他漏洞。 Microsoft 建议将参数化的做法至少保留 16 年。而且，尽管如此，我很震惊地发现 SQL 注入仍然是领先的——即被黑客攻击最多的——漏洞。
@Skary Google“sql 走私”。黑客没有什么比想办法绕过阻止他们的尝试更好的办法了。