Question

针对SQL注入漏洞的典型控制是使用绑定变量（cfqueryparam标记），字符串数据验证以及转向实际SQL层的存储过程。这很好，我同意，但如果该网站是遗留的，它具有很多动态查询。然后，重写所有查询是一项艰巨的任务，需要进行大量的回归和性能测试。我正在考虑使用动态SQL过滤器并在调用cfquery之前调用它以进行实际执行。

我在CFLib.org（http://www.cflib.org/udf/sqlSafe）中找到了一个过滤器：

<cfscript>
/**
* Cleans string of potential sql injection.
*
* @param string      String to modify. (Required)
* @return Returns a string.
* @author Bryan Murphy (bryan@guardianlogic.com)
* @version 1, May 26, 2005
*/
function metaguardSQLSafe(string) {
var sqlList = "-- ,'";
var replacementList = "#chr(38)##chr(35)##chr(52)##chr(53)##chr(59)##chr(38)##chr(35)##chr(52)##chr(53)##chr(59)# , #chr(38)##chr(35)##chr(51)##chr(57)##chr(59)#";

return trim(replaceList( string , sqlList , replacementList ));
}
</cfscript>

这似乎是一个非常简单的过滤器，我想知道是否有办法改进它或提出更好的解决方案？

Answer 1

如果该网站是遗产网站，该怎么办？它具有很多动态查询功能。然后，重写所有查询是一个艰巨的任务，它需要一个广泛的回归期和性能测试。

是的，但是如果您执行任何重大更改，包括使用类似您提议的功能，就会出现这种情况。

所以我仍然建议进行一些测试设置，重构以使用合理的框架，然后修复查询以使用cfqueryparam。

这个特定的功能是一堆废话，不做它声称要做的事情，并且有可能破坏东西（错误地超过最大长度）。

它只需将--变为--而将'变为' - 这不是SQL注入保护！

所以是的，如果你仍然希望沿着这条路走下去，找一个不同的功能，但我建议你进行适当的重构。

Answer 2

显然，你有很多工作要做。但是当你卷起袖子时，你可能做的一件小事就是减少注入攻击造成的一些潜在损害，就是创建几个数据源，然后通过仅限{{{}的数据源运行所有select - 只查询1}}语句。对于所有数据源，请确保禁用select，grant，revoke，create和alter等内容。

Answer 3

您可以尝试Portcullis。它是一个开源CFC，可用于扫描SQL注入和XSS攻击的URL，FORM和COOKIE范围。它不能保证保护，但在您重写查询时，至少可以提供一些保护。好处是它可以包含在Application.cfm / cfc中，以大约4行代码的代价扫描每个CF页面请求的范围。

Answer 4

将此编码放入application.cfm文件中。

＆lt; cfif FindNoCase（“DECLARE”，cgi.query_string）和FindNoCase（“CAST”，cgi.query_string）和FindNoCase（“EXEC”，cgi.query_string）＆gt; ＆lt; cfabort showerror =“哎呀.. !!这是SQL注入。” ＆GT; ＆LT; / CFIF＆GT;

http://ppshein.wordpress.com/2008/08/23/sql-injection-attacks-by-store-procedure/

http://ppshein.wordpress.com/2008/08/28/block-ip-in-coldfusion/

用于动态查询的SQL注入保护

4 个答案: