php/mysqli (prepared statements + bind params) 如何防止 SQL 注入？答案

【问题标题】：How php/mysqli ( prepared statements + bind params ) protect against SQL Injection?php/mysqli (prepared statements + bind params) 如何防止 SQL 注入？
【发布时间】：2011-11-28 17:40:15
【问题描述】：

php/mysqli（使用准备好的语句+绑定参数）如何防止 SQL 注入？ Mysqli 仅对变量应用“real_escape_string”或做其他事情？

我可以说下面的函数在使用mysqli +prepared statements + bind params时完全没用吗？

function no_injection ( $data ) {
$data = trim(strip_tags($data)); // no htm in this case.
$data = get_magic_quotes_gpc() == 0 ? addslashes($data) : $data; // useless.
$data = preg_replace("@(--|\#|;)@s", """, $data); // <--- USELESS ?
return $data;
}

谢谢

【问题讨论】：

标签： mysqli sql-injection

【解决方案1】：

addslashes() 不支持 unicode。有相当数量的 unicode 序列看起来像普通文本，但在被非 unicode 感知代码处理时会变成不同的东西，允许恶意用户构造一个“有效”的 unicode 字符串，一旦添加斜杠破坏字符串，就会引发 SQL 注入攻击.

您的正则表达式也是如此。您尚未启用 unicode 模式，因此它可能会允许恶意 unicode 字符泄漏并成为常规 iso8859 字符，从而破坏查询。

除此之外，每个数据库都有自己的转义要求。 MySQL 理解并遵守转义的反斜杠，因此 ' 变为 \'。但是另一个数据库可能使用'' 作为转义的'，并且为该数据库应用MySQL 转义序列将毫无用处。

准备好的语句允许查询和数据完全分离。当您手动编写自己的查询时，数据库服务器绝对无法知道查询字符串的一部分可能是恶意的并对其进行特殊处理。它只看到一个查询字符串。

使用prepared statements，查询主体和进入查询的数据是分开的，直到它们到达数据库服务器，数据库服务器可以自己处理转义。

在现实世界中，递给某人一条有毒的面包和递给他们一篮子牛奶、鸡蛋、面粉、一瓶毒药、酵母等之间的区别……没有办法知道里面有毒直到你吃完面包然后死去。在使用成分（即准备好的语句）时，数据库服务器将看到那瓶毒药并知道如何处理它。

【讨论】：

【解决方案2】：

它还缓存查询，这将通过更多“调用”来提高性能。

-> http://dev.mysql.com/doc/refman/5.1/en/c-api-prepared-statements.html -> Should I use prepared statements for MySQL in PHP PERFORMANCE-WISE?

【讨论】：