使用sql转义的动态mysql查询是否与准备好的语句一样安全？

Question

我有一个应用程序，通过将动态mysql查询与mysql（mysqli）实际转义字符串结合使用，将大大受益。如果我运行了通过mysql真正的转义从用户那里收到的所有数据，那么它与使用mysql预准备语句一样安全吗？

Answer 1

虽然标题中的问题是模棱两可的， 可以 解释为“动态mysql查询的 每个部分 格式 是否正确……”，因此有肯定的答案，但正文中的问题
不是 ：

如果我运行了通过mysql真正的转义从用户那里收到的所有数据，那么它与使用mysql预准备语句一样安全吗？

如果您更仔细地看这个问题，您将理解，这只是 魔术引述的 化身！此不受欢迎，不推荐使用和已删除的功能的确切目的是“通过转义运行所有用户输入”。
如今，每个人都知道魔术引号是不好的。 那为什么要肯定的答案呢？

好的，似乎需要再次解释，为什么批量转义不好。

问题的根源是一个非常强烈的妄想，几乎每个PHP用户
都对它抱有幻想：每个人都有一个奇怪的信念，即逃避对“危险字符”（它们是什么？）进行某些操作，使它们“安全”（如何？）。不用说，这只是一个完整的垃圾。

事实是：

• 逃逸不会“消毒”任何东西。
• 逃逸与注射无关。
• 转义与用户输入无关。

转义只是一种 字符串格式 而已。
当需要时-尽管有注射的可能，但仍需要它。
当您不需要它时，即使有一点注射也无济于事。

说到与准备好的语句的区别，至少存在一个问题（在sql-injection标记下已经多次提及）：这样
的代码

$clean = mysql_real_escape_string($_POST['some_dangerous_variable']);
$query = "SELECT * FROM someTable WHERE somevalue = $clean";

将帮助您避免注射。
Beause转义只是字符串格式化工具，无论如何都不是防止注入的工具。
去搞清楚。

但是，转义与准备好的语句有一些共同点：
如果发生以下情况，它们都不能保证您不会被注入

• 您仅在臭名昭著的“用户输入”上使用它，而不管构建ANY查询的严格规则，尽管有数据源。
• 如果您需要插入的不是数据，而是标识符或关键字。

为了安全起见，请参阅我的答案，以解释FULL
sql注入保护的操作方法

长话短说：只有在您对初始陈述进行2次必要的更正和1次补充之后，您才能认为自己是安全的：

如果我运行 了 通过mysql真正的转义 从用户那里收到的 所有数据 ， 并且始终将其括在引号中
（并且，如ircmaxell所提到的，mysqli_set_charset()它用于使mysqli_real_escape
string（）实际上起作用了（在这种罕见的情况下，使用一些奇怪的编码，例如GBK））是否与使用mysql准备好的语句一样安全？

遵循这些规则-是的，它与本地准备好的语句一样安全。