这段代码真的可以对抗 SQL 注入吗？ [复制]答案

【问题标题】：Will this code actually work against SQL-injection? [duplicate]这段代码真的可以对抗 SQL 注入吗？ [复制]
【发布时间】：2011-05-28 21:43:23
【问题描述】：

可能重复：
PHP: the ultimate clean/secure function

我在这里找到了这个代码 sn-p：http://snipplr.com/view/12853/clean-variables-from-sql-injections/

作者声称：

这个小功能有助于解决 SQL 注入的常见安全问题，它可以清理任何全局变量，如 $POST、$GET、$_SERVER 等，并转义不安全的字符。

这段代码安全吗？

function _clean($str){
  return is_array($str) ? array_map('_clean', $str) : str_replace("\\", "\\\\"
       , htmlspecialchars((get_magic_quotes_gpc() ? stripslashes($str) : $str)
       , ENT_QUOTES));
}

//usage call it somewhere in beginning of your script
_clean($_POST);
_clean($_GET);
_clean($_REQUEST);// and so on..

请告诉我这是否安全，因为在我看来它是陪审团操纵的。

【问题讨论】：

99% 确定它是 borken :-)

标签： php sql-injection

【解决方案1】：

通用代码清理函数总是一个坏主意。他们会以一种或另一种方式破坏您的数据。永远不要使用它们；在数据被使用之前对其进行清理，并采用适合预期用途的正确清理方法。

重复：PHP: the ultimate clean/secure function

【讨论】：

【解决方案2】：

如果您需要为 mysql 数据库转义特殊字符，只需使用 mysql_real_escape_string。我想其他数据库也支持类似的功能。

这个片段尝试了一些愚蠢的替换，可能非常安全，但也可能会弄乱您的数据。为什么要重新发明轮子？

【讨论】：

【解决方案3】：

您为什么不直接为您的数据库使用内置的转义/参数化功能？我同意它看起来像陪审团一样，使用制作数据库库的人构建的功能。

【讨论】：

【解决方案4】：

这不安全（没有addslashes 或mysql_real_escape_string），性能也不是最优的（每个变量都调用get_magic_quotes_gpc）。

【讨论】：