mysql_real_escape_string（）是否完全可以防止SQL注入？
在http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-
sheet/?akst_action=share-
this上
，有一节声称您可以使用某些亚洲字符编码绕过mysql_real_escape_string
用BIG5或GBK绕过mysql_real_escape_string（）
“注入线”
に关する追加情报：以上字符是中国Big5
这是真的吗？如果是的话，如果您无法访问准备好的陈述，那么如何保护您的网站呢？
问题答案：
根据Stefan Esser的说法， “mysql_real_escape_string()[ SET NAMES使用时不安全] 。”
来自他的博客的解释：
SET
NAMES通常用于将编码从默认设置切换到应用程序需要的设置。这是mysql_real_escape_string不知道的方式完成的。这意味着，如果您切换到允许反斜杠作为2nd
3rd 4th…字节的多字节编码，则会遇到麻烦，因为mysql_real_escape_string无法正确转义。UTF-8是安全的…更改编码的安全方法是
mysql_set_charset，但这仅在新的PHP版本中可用
他确实提到UTF-8是安全的。
-
问题内容： 我正在与Hibernate合作保护我的网站免受SQL Injection。 我听说Hibernate Criteria API比HQL更强大。Hibernate Criteria Api是否可以完全防止SQL注入？ 问题答案： 是的，它确实。 Criteria API以及HQL或JPQL中的查询参数均会转义参数，并且不会执行恶意SQL。 仅在您将参数简单地串联到查询中时，才会暴露此漏洞
-
问题内容： 今天早些时候，有人问了有关Web应用程序中输入验证策略的问题。 在撰写本文时，最高答案建议仅使用和。 我的问题是：这是否总是足够？还有更多我们应该知道的吗？这些功能在哪里分解？ 问题答案： 对于数据库查询，请始终尝试使用准备好的参数化查询。在和库支持这一点。这比使用转义功能（例如）更加安全。 是的，实际上只是一个字符串转义功能。这不是魔术子弹。它所要做的就是逃避危险字符，以便可以安全地
-
问题内容： 我遇到了一群黑客。他们几次入侵了我客户的网站，我的客户更加生气:(我的客户丢失了他的数据库（有数百条记录），不得不输入所有:( 现在，我将进行更多介绍。 固定文件权限 更改了ftp和主机登录信息 清除所有远程mysql访问 现在正在处理SQL注入问题。我在管理面板登录参数中添加了mysql_real_escape_string。所以我还应该在哪里使用mysql_real_escape_
-
问题内容： 在PHP手册中，有一条注释： 注意：如果不使用此功能对数据进行转义，则该查询容易受到SQL注入攻击的攻击。 这足以进行反SQL注入吗？如果没有，您能举个例子和一个好的反SQL注入解决方案吗？ 问题答案： 通常足以避免SQL注入。不过，这确实取决于它是否没有错误，即它 存在 脆弱性的可能性很小（但是这还没有在现实世界中体现出来）。准备好的语句是在概念上完全排除SQL注入的更好的替代方法。
-
问题内容： 可能重复： 绕过mysql_real_escape_string（）的SQL注入 我还没有看到任何评价或没有过时的信息。因此，存在一个问题：mysql_real_escape_string（）是否完全可以防止SQL注入？但是它已经非常过时了（它从‘09开始），所以从‘12的php 5.3和mysql 5.5开始，它是否可以完全保护？ 问题答案： mysql_real_escape_st
-
问题内容： 假设我有这样的代码： PDO文档说： 准备好的语句的参数不需要用引号引起来。司机为您处理。 那真的是我避免SQL注入所需要做的一切吗？ 真的那么容易吗？ 您可以假设MySQL会有所作为。另外，我真的只是对针对SQL注入使用准备好的语句感到好奇。在这种情况下，我不在乎XSS或其他可能的漏洞。 问题答案： 简短的回答是“ 否” ，PDO准备将不会为您防御所有可能的SQL注入攻击。对于某些晦