在旧的经典ASP网站中清理mysql的好方法是什么？

Question

对于电子产品制造商来说,我是一个非常古老,非常大且写得非常糟糕的经典ASP网站的维护者(但幸运的是不是创建者).

安全是一个笑话.这是在将输入放入MySQL口之前清理输入的唯一方法:

Function txtval(data)
    txtval = replace(data,"'","'")
    txtval = trim(txtval)
End Function

productid = txtval(Request.QueryString("id"))
SQL = "SELECT * FROM products WHERE id = " & productid
Set rs = conn.execute(SQL)

因此,该站点不幸(但也许并不奇怪)是SQL注入攻击的受害者,其中一些是成功的.

上面采用的简单方法还不够.也没有使用Server.HTMLEncode.逃避斜线也无济于事,因为攻击非常复杂:

product.asp?id=999999.9+UnIoN+AlL+SeLeCt+0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39,0x393133353134353632342e39,0x393133353134353632352e39,0x393133353134353632362e39

上面的url(从访问日志中获取的任意尝试)给出了来自站点的folling响应:

Microsoft OLE DB Provider for ODBC Drivers error '80004005'

[MySQL][ODBC 5.3(w) Driver][mysqld-5.1.42-community]
The used SELECT statements have a different number of columns

/product.asp, line 14

这意味着注入完成但在这种情况下没有成功获取任何数据.但是其他人也这样做.

该网站由数百个ASP文件组成,其中意大利面条代码总计达数千行而没有太多结构.因此,不能选择参数化查询.这项工作将是巨大的,也容易出错.

但有一件好事是代码中的所有输入参数都一致地通过txtval函数传递,因此通过增加函数可以更好地完成它.此外,由于所有SQL调用都是完成的,conn.execute(SQL)所以用例如搜索和替换它是非常简单的.conn.execute(sanitize(SQL))所以这里也有机会对此做些什么.

鉴于这种情况,我有哪些选择来阻止或至少最小化SQL注入的风险？

任何输入都非常感谢.

更新:

1.我明白参数化查询是处理问题的正确方法.我在创建网站时自己使用它.但考虑到网站的构建方式和大小,它需要1-2个月的时间来修改,测试和调试它.即使这是我们最终的结果(我怀疑),我现在需要做点什么.

2.用html实体替换不是拼写错误.它用其html实体替换单引号.(我没有制作代码!)

3.在上面的具体示例中,使用CInt(id)可以解决问题,但它可以是任何东西,而不仅仅是数字输入.

更新2:

好的,我知道我不是要求正确的解决方案.我从一开始就知道.这就是为什么我写"鉴于情况".

但尽管如此,对于MySQL的关键字,比如过滤输入select,union等至少会做的更好.不好,但好一点.这就是我要求的,让它变得更好的想法.

虽然我感谢您的评论,但告诉我唯一不错的选择是使用参数化查询并没有真正帮助.因为我知道已经:)

Answer 1

我不会放弃参数化查询。它们是您可以用来保护自己免受 SQL 注入攻击的最佳工具。如果您的计划是替换所有这些调用：

conn.execute(SQL)

对于这些电话：

conn.execute(sanitize(SQL))

那么您已经在考虑修改与 SQL 的每个交互（顺便说一句，不要忘记Command.Execute()and Recordset.Open()，它也可以用于运行 SQL 语句）。由于您已经计划更改这些调用，因此请考虑调用自定义函数来运行该语句。例如，替换：

set rs = conn.execute(SQL)

和：

set rs = MyExecute(SQL)

然后使用您的自定义函数来使用对象来设置适当的参数化查询Command。您需要巧妙地解析此自定义函数中的 SQL 语句。识别子句中的值where，确定它们的类型（也许您可以查询表架构），并相应地添加参数。但这是可以完成的。

您还可以借此机会清理输入。例如，使用RegExp对象快速从数字字段中剥离。[^0-9\.]

但您仍然有机会从此函数返回一个记录集，该记录集将用于将值直接写入页面，而无需先进行 HTML 编码。这是一个真正令人担忧的问题，尤其是因为听起来您的网站过去已经成为攻击目标。我不会相信来自您数据库的任何数据。我在这里看到的唯一选项（不涉及触摸每个页面）是返回一个“干净”的 HTML 编码记录集，而不是默认记录集。

不幸的是，你还没有脱离困境。XSS 攻击可以通过 QueryString 参数、cookie 和表单控件来完成。在“修复” SQL 注入问题后，您知道 XSS 仍然很可能存在，您会感觉有多安全？

我的建议？向您的主管解释困扰您网站的安全威胁，并说服他/她需要进行彻底审查或完全重写。向“旧的、已经运行的网站”投入似乎需要投入大量资源，但是当有人破坏您的网站或截断您的数据库表时，您会希望投入这些时间。