如何在SQL注入中“参数化查询/准备好的语句”比转义用户输入更好

Question

有很多articles告诉我们使用parametrized queries而不是escaping user input。但没有给出任何例子。我想知道一个真实的例子：“参数化查询/准备语句”可以阻止SQL注入，而转义用户输入则不能。您能给出一个示例说明，当查询的用户输入仍然包含一个特殊字符以造成伤害时，parameterized query可以防止SQL注入攻击吗？例如，parameterized queries可以处理但escaping user input不能处理的查询

查询如= ' or 1=1-- //I想知道是否有类似的查询“参数化查询/准备好的语句”可以防止SQL注入，但“转义用户输入”不能

Answer 1

问:您能给出一个例子，当用户输入到查询时，参数化查询会防止SQL注入攻击，但仍然包含一个特殊字符以造成危害吗？

答:有一些多字节字符在代码中利用，这些字符不能正确地解释字符集，从而导致转义机制出现漏洞。(其中“转义字符串”认为它在处理特定编码的字符串，但实际字节采用不同的编码方式，并且偷偷地将单引号滑动到SQL文本中。)

但是，我并不认为这是使用bind占位符准备语句的最有力的论据。

一个强有力的论点是，当我们查看代码时，我们看到的是静态SQL文本，而不是动态生成的.

 $sql = 'SELECT fee, fi FROM fo WHERE fum = ?'; 
 $dbh->prepare($sql);

我们看到了代码，我们看到了SQL文本.我们立即意识到，SQL文本不可能是我们所看到的。我们不需要查看代码中的其他地方；我们可以在两行代码中看到它。

当我们看到这个：

 $sql = "SELECT fee, fi FROM fo WHERE fum = $fumval";

这是双引号，有可变的解释。$fumval是否保证包含在$fumval文本中是安全的，$fumval从何而来？应该在$fumval周围有单引号，还是保证它已经包含在单引号中？

好吧，也许在那之前有一条线：

 $fumval = $dbh->quote($unsafe_fumval);

如果该行不在生成SQL文本的位置，我们需要检查.我们保证$fumval是安全的吗？

重点是这个..。SQL正在动态构建。如果这样做可能会更好：

$sql = 'SELECT fee, fi FROM fo WHERE fum = ' . $dbh->quote($unsafe_fumval);

对于一个简单的陈述来说，也许是另一个半打中的六个。但是，当SQL语句变得更大，涉及多个表以及数十个列引用和值时，动态构造就更难验证其中没有任何问题。

是否可以使用动态生成的SQL和“转义字符串”处理值来编写安全代码？是。

是否有可能编写带有动态生成SQL文本的准备语句的易受攻击代码？是。

它实际上是静态SQL文本的模式，传递通过绑定占位符提供的值是为了我们的利益.以一种我们可以识别为不容易受到SQL注入影响的方式编写的代码。