mysqli准备好的语句是否完全免受mysql注入?
所以我一直在阅读很多关于准备好的陈述,并且不断得到关于准备好的陈述如何防止mysql注入的各种答案。有些人说它完全覆盖了它,而另一些人则说它们仍然有一些小的工作或某些事情。几乎我只是想确认这个代码,我是安全的,知道居然有准备语句中的任何孔:mysqli准备好的语句是否完全免受mysql注入?
<?php
ignore_user_abort(true);
$user = $_REQUEST['username'];
$pass = $_REQUEST['password'];
if (isset($user) && isset($pass)) {
require('/var/www/data/config.php'); //contains the db connection
if ($stmt = mysqli_prepare($mysqli, "SELECT password FROM users WHERE username=?")) {
mysqli_stmt_bind_param($stmt, 's', $user);
mysqli_stmt_execute($stmt);
mysqli_stmt_bind_result($stmt, $gpass);
mysqli_stmt_fetch($stmt);
mysqli_stmt_close($stmt);
if ($gpass) {
require('/var/www/data/handles/fCrypt.php');
$chk = verify($pass, $gpass); //custom blowfish validation
if ($chk) {
//password correct, continue
} else {
mysqli_close($mysqli);
//echo invalid password stuff
}
} else {
mysqli_close($mysqli);
//echo invalid username stuff
}
} else {
mysqli_close($mysqli);
die('Query Error');
}
} else {
die('Invalid Request');
}
?>
我不是这个话题的专家,但我会说安全首先是一个实践问题。但是,只要你遵循它,那么拥有使它更容易遵循正确方式的工具确实有帮助。
对于该工具如何帮助您实现该目标存在限制:评论中提到的that post on PDO usefullness涵盖了它们非常好。 对于他们中的一些人来说,很难理解为什么(IN
子句问题可能是技术问题),但其他人很有意义:对于查询的语法部分(如表或列名称) - 除此之外对于数据库引擎编译和优化查询而不知道它正在处理的是哪一列或哪一个表而言是相当不利的,因此不应该有任何这样的数据来自用户的理由(人们会认为数据库管理工具是可能发生这种情况的一种情况,但该程序类别已经与最终用户具有一定程度的信任关系)。
db元数据已知和操纵的唯一地方是程序。这个断言真的意味着它是ok动态构建查询,逐位构建查询,甚至使用库来帮助您确保查询在语法上是正确的,只要您遵守核心规则:不泄漏数据库架构到用户空间。
关于你的代码,在我看来,你已经遵循规则,我没有看到任何危险的陈述。
这是不切实际的立场。必须为每一个案件做好准备,而不仅仅是否认这种可能性。考虑我上面链接的SafeMysql库。它也提供对标识符的保护 – 2013-04-04 07:42:27
本质上是PDO准备语句安全的副本(http://stackoverflow.com/questions/1314521/how-safe-are-pdo-prepared-statements) – deceze 2013-04-04 06:49:11