这足以防止 SQL 注入吗？

Posted 2023-02-19

【中文标题】这足以防止 SQL 注入吗？

【英文标题】：Is this Enough to Secure againts SQL Injections?

【发布时间】：2012-07-30 20:16:53

【问题描述】：

我正在尝试使用 MS SQL 2008 R2（Express Edition）保护一个较旧的经典 asp 网站（大约有 1,000 个 (.asp) 页）。

我找到了一个关于如何参数化查询的代码（见下文），该代码看起来是我最容易理解并在所有需要更改的页面上使用的代码。

我的问题是：如果我要转换所有的 ms sql 查询（看起来像下面的代码），是否足以防止 ms sql 注入攻击？还是我需要添加/更改更多内容？

感谢您的帮助...

代码如下：

    set objCommand = Server.CreateObject("ADODB.Command")  
    strSql = "SELECT * FROM users WHERE username=? AND password=?"
    ...  
    cmd1.Parameters(0) = Request.Form("login")
    cmd1.Parameters(1) = Request.Form("password")
    ... 

【问题讨论】：

就SQL注入而言应该可以。我仍然是存储过程和命名参数的粉丝。 SP 提供了明确定义的接口，并且作为 DB 对象，可以应用安全性。显式定义参数及其数据类型有助于确定接口。可以提供参数的默认值并在 SP 内完成验证。

@HABO 将 kd7 提供的代码（参见下面的答案#2）解决所有问题，还是仍然存在可能导致问题的漏洞？ （很抱歉，我知道这可能是一个菜鸟问题，但我只是想了解我必须做些什么才能使它成为一个安全的网络应用程序。并开始更改 1,000 多个页面）非常感谢...

它适用于一个简单的网站，但在较大的环境中成为维护难题。部分问题是散布在各处的 SQL 的 sn-ps 很少。应该是一个小的数据库更改和更新的 SP 变成了搜索所有包含 SQL 的地方，或者动态构建它。 SP 的执行计划被保留并在每次调用时重复使用（除非您指定WITH RECOMPILE）。这通常有助于提高性能。 SP 可以提供对调用者无法访问的数据的有限访问，这在具有多个应用程序的大型项目中很重要。

@HABO 非常感谢您的意见，请您指导我阅读教程或您批准我（所有这一切中的菜鸟）阅读的内容，一些我能理解的材料?非常感谢您为 HABO 所做的一切。

你是here。试试here 和here。 Advanced SQL security topics. Alternate viewpoint. 维护的问题是经验和环境的问题。

【参考方案1】：

我已经有一段时间没有看到旧的 Adodb 命令语法了，但我想你会想要这样的东西：

set objCommand = Server.CreateObject("ADODB.Command")
strSql = "Select * From users where username=@username and password=@password"
objCommand.Parameters.Append.CreateParameter
         ("@username", adVarChar, adParamInput, 50, Request.Form("login"))
objCommand.Parameters.Append.CreateParameter
         ("@password", adVarChar, adParamInput, 50, Request.Form("password"))

与往常一样，不要创建没有类型安全参数编码的动态 sql 语句，我认为即使是老式 ADO 也通过 CreateParameter 提供了这一点。

【讨论】：

非常感谢上面的例子，它真的帮助我更好地理解如何做到这一点。我完全是个菜鸟，但我想了解它是如何工作的，所以我确保我做的一切都是正确的。

【参考方案2】：

是的，您在问题中提供的代码受到 Sql 注入的保护。

但是，as noted in this article on mitigating Sql Injection，您的代码将出现“一个较小的性能问题，因为 ADODB 在执行查询之前将不得不往返 SQL 以确定参数类型。”

您可以通过在代码中使用CreateParameter 显式指定参数类型来解决此问题