php/mysqli（准备好的语句和绑定参数）如何防止 SQL 注入？
php/mysqli（带有准备好的语句+绑定参数）如何防止 SQL 注入？ Mysqli 仅对变量应用“real_escape_string”还是做其他事情？
我可以说，当使用 mysqli + 准备好的语句 + 绑定参数时，下面的函数完全没用吗？
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;
}
谢谢
How php/mysqli ( with prepared statements + bind params ) protect against SQL Injection ?
Mysqli applies only "real_escape_string" for variables or do something else?
May i say that the function below is totally useless when using 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;
}
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
addslashes() 不支持 unicode。有相当多的 unicode 序列看起来像普通文本，但在由非 unicode 识别代码处理时会变成不同的东西，从而允许恶意用户构造一个“有效”unicode 字符串，一旦 addslashes 破坏该字符串，就会引发 SQL 注入攻击。
您的正则表达式也是如此。您尚未启用 unicode 模式，因此它可能会允许恶意 unicode 字符泄漏并成为常规的 iso8859 字符，从而破坏查询。
除此之外，每个数据库都有自己的转义要求。 MySQL 理解并尊重反斜杠进行转义，因此
'变为\'。但另一个数据库可能会使用''作为转义的'，并且为该数据库应用 MySQL 转义序列将是无用的。准备好的语句允许查询和数据完全分离。当您手动编写自己的查询时，数据库服务器绝对无法知道查询字符串的一部分可能是恶意的并对其进行特殊处理。它只看到一个查询字符串。
使用准备好的语句，查询主体和进入查询的数据在到达数据库服务器之前保持分离，并且数据库服务器可以自行处理转义。
在现实世界中，这就像递给某人一条有毒的面包和递给他们一篮子牛奶、鸡蛋、面粉、一瓶毒药、酵母等之间的区别……没有办法知道面包里有毒，直到吃完之后就死了。当有了成分（又名准备好的语句）时，数据库服务器将看到那瓶毒药并知道如何处理它。
addslashes() is NOT unicode aware. There's a fair number of unicode sequences that look like normal text, but turn into different things when processed by non-unicode aware code, allowing a malicious user to construct a "valid" unicode string that comes an SQL injection attack once addslashes trashes the string.
The same goes for your regex. You've not enabled unicode mode, so it can potentially allow malicious unicode characters to leak through and become regular iso8859 chars that'll break the query.
Beyond that, each database has its own escaping requirements. MySQL understands and honors the backslash for escaping, so
'becomes\'. But another database might use''as the escaped', and applying a MySQL escape sequence for that database will be useless.Prepared statements allow a complete separation of query and data. When you write your own query manually, the DB server has absolutely no way of knowing that a part of the query string is potentially malicious and treat it specially. It just sees a query string.
With prepared statements, the query body and the data going into the query are kept separate up until they reach the database server, and the db server can handle the escaping itself.
In real world terms, it's the difference between handing someone a loaf of poisoned bread, and handing them a basket of milk, eggs, flour, bottle of poison, yeast, etc... There's no way to tell there's poison in the bread until after you've eaten it and drop dead. While with the ingredients (aka prepared statement), the DB server will see that bottle of poison and know how to handle it.
它还缓存查询，这将通过更多“调用”来提高性能。
-> http://dev.mysql.com/ doc/refman/5.1/en/c-api-prepared-statements.html
-> 我应该在 PHP 性能中使用 MySQL 的预准备语句吗-WISE？
It also caches the queries which will increase performance with more "calls".
-> 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?