准备语句是否可以保护您的数据库？
我知道有些人可能会回答这个问题，但是我的问题来自于您和您的答案。我正在阅读有关SQL注入以及如何保护数据库的过去两个小时的问答。我看到的大量网页和教程也是如此。
我发现有一半人声称prepare语句确实可以保护您的数据库，而另外50人则声称不是。
另一方面，我读到mysql_real_escape_string可以完成这项工作，而其他人则说不行。
我的问题是谁相信？
另外，这是适当的准备声明吗？
$stmt = $dbh->prepare("SELECT phpro_user_id, phpro_username, phpro_password FROM phpro_users
WHERE phpro_username = :phpro_username AND phpro_password = :phpro_password");
/*** bind the parameters ***/
$stmt->bindParam(':phpro_username', $phpro_username, PDO::PARAM_STR);
$stmt->bindParam(':phpro_password', $html" target="_blank">phpro_password, PDO::PARAM_STR, 40);
/*** execute the prepared statement ***/
$stmt->execute();
问题答案：
准备好的语句则没有。绑定参数可保护语句（而不是整个数据库）的安全，只要所有不可信数据都通过参数传递而不是插值到语句中即可。当人们使用准备好的语句时，他们几乎总是也使用绑定的参数，因此这两个名称通常会混合在一起。
- 准备陈述
- 以变量作为附加参数的运行语句
mysql_real_escape_string 几乎总是可以完成这项工作，但是由于它在流程中增加了其他步骤，因此更容易出现人为错误。
- 转义 每个 变量
- 将变量连接到SQL语句
- 运行语句
-
我正在为我的sqlite日志数据库使用准备好的语句。 我的线程每50ms运行一次，将日志缓冲区中的内容写入数据库。 目前，我正在对每个线程运行一个新的准备好的语句批处理，并在所有数据线写入后关闭它们。 现在我想知道是否最好将准备好的语句保存在内存中，并仅在线程关闭/中断时关闭它？ 我之所以进行这种预优化，是因为我希望这个日志线程对主应用程序性能的干扰尽可能小，我可以想象每50秒分配/解析/验证资源
-
我可能有一个简单的编码问题，但我无法解决。我在MySQL数据库中有英文或中文的地址，所以我使用了utf8_unicode_ci。我从数据库中检索我的汉字没有问题，但我不能在准备好的请求中使用汉字。 我解释说：如果我打 我会得到一个结果，因为其中一个地址包含“”但如果我尝试使用一个准备好的请求： 如果$_post[“address”]在英文中有效,在中文中就不行了：p 编辑： 当请求show变量时，
-
问题内容： 假设我有这样的代码： PDO文档说： 准备好的语句的参数不需要用引号引起来。司机为您处理。 那真的是我避免SQL注入所需要做的一切吗？ 真的那么容易吗？ 您可以假设MySQL会有所作为。另外，我真的只是对针对SQL注入使用准备好的语句感到好奇。在这种情况下，我不在乎XSS或其他可能的漏洞。 问题答案： 简短的回答是“ 否” ，PDO准备将不会为您防御所有可能的SQL注入攻击。对于某些晦
-
我正在使用我生成的一个准备好的语句，但在Java抛出的语句上出现了语法错误。然而，当我将PS的toString复制并粘贴到数据库的phpmyadmin中时，它的执行完美无缺。有什么想法会出错吗，我很难理解？ 编辑：更改为PS.ExecuteUpdate（查询）；还是不起作用。
-
问题内容： 对于此查询，有必要使用吗？ 任何改进或查询是否还好？ 在这种情况下，查询速度很重要。 问题答案： 否，准备好的查询（正确使用时）将确保对数据进行正确的转义以进行安全查询。您有点正确地使用它们，只需要更改一件事。因为您使用的是“？” 占位符，最好通过execute方法传递参数。 请注意，如果要将其输出到页面，数据库清理并不意味着可以在HTML中安全显示，因此也可以在其上运行htmlspe
-
问题内容： 在PDO :: Prepare页上指出： “并且通过消除对参数的手动引用来帮助防止SQL注入攻击” 知道这一点，是否有一个像mysql_real_escape_string（）这样的PHP函数可以照顾到PDO的转义？还是PDO会为我做好一切转义？ 编辑 我现在意识到我问了一个错误的问题。我的问题确实是，“ PDO会为我做什么？” 我现在通过这些答案意识到，它实际上仅消除了对引号进行转义