SQL注入漏洞

Question

我们有一个ASP.NET/C#网站。我们的开发人员在亚洲离岸，我刚刚发现他们一直将原始SQL放在网站前端上。

我担心我们现在容易受到SQL注入攻击。有没有人知道如何检测网站中的漏洞，以及关闭这些漏洞的最佳方法？

- Rup

---

首先要做的是从前端和后端中删除所有的内联（原始）SQL，并仅使用存储过程将值作为参数传递。 - Davide Piras

前端是指在表单中的隐藏输入和其他东西吗？ - Corbin

是的，指的是表单/页面上的输入字段。 - Rup

存储过程与正确使用参数化的普通 SQL 相比并没有增加更多安全性，但会使部署变得更加复杂；在我看来，这里不需要使用存储过程，只需正确使用参数即可。 - Marc Gravell

@Marc，我知道，但通常最好将存储过程放在服务器上进行控制和分析，优化，分析，预编译等等……而不是将同样的逻辑散布在整个C#代码中。然后修复一个小问题需要重新部署二进制文件，当模式发生变化时你是不安全的……无论如何，我理解你的观点，这里讨论的不是SPROC与SQL的前端界面之争…… - Davide Piras

@Davide，也许我有偏见，因为我们这里有一个非常简单的部署策略；部署二进制文件同样容易。存储过程很麻烦，因为时间问题......如果它改变了任何行为，无论你如何切分服务器群集，在升级一半的服务器、运行SPROC脚本，然后非常快地切换集群时都会出问题......如果应用程序层拥有SQL，那就没有问题。 - Marc Gravell

Answer 1

尝试从前端检测漏洞可能有所帮助，但你真正应该看的是代码，特别是与DbCommand、SqlCommand等相关的所有代码。关键点，正如你清楚知道的那样，是永远不要将用户输入连接到查询中，而是将其参数化。有好的工具可用，可以使这种参数化易于操作，或者至少比手动操作更容易。例如，如果你有：

using(var cmd = conn.CreateCommand()) {
    cmd.CommandText = "delete from Orders where id = " + id;
    cmd.ExecuteNonQuery();
}

如果涉及到IT技术，像dapper-dot-net这样的工具能够让您做以下事情：

conn.Execute("delete from Orders where id = @id", new {id});

这是一种代码量较少的方法，主要是复制粘贴，但它完全可以防止注入攻击，并允许重用查询计划。

- Marc Gravell

Answer 2

请查看Scrawlr或者Acunetix，这是用于扫描网站漏洞的工具，特别是SQL注入漏洞。另一种方法是注册PCI-DSS合规公司之一。我们使用SecurityMetrics，通常银行会提供折扣。

- PMC

---

有用的链接，但是解释一下这些链接是什么会更有帮助，这样就不需要跟着链接去看它指向哪里了。 - Davide Piras

Answer 3

首先请查看这篇文章：如何在ASP.NET中防止SQL注入

我建议您确保所有的操作都使用存储过程，或者如果您使用常规的SQL命令，则只能使用参数，并且永远不要动态构建CommandText属性的内容。

- Asher

---

存储过程并不比正确使用参数化的常规SQL提供更多安全保障，但会使部署变得更加复杂；在我看来，在这里不需要使用存储过程，只需正确使用参数即可。 - Marc Gravell

Answer 4

好的，我会要求他们发送源代码并进行代码查看（或由相对经验丰富的开发人员完成）。

- Pleun

---

我认为退款是必要的！ - Chris Dunaway