只有 str_replace 的 Sql 注入保护答案

【问题标题】：Sql Injection protection with only str_replace只有 str_replace 的 Sql 注入保护
【发布时间】：2015-09-09 10:46:24
【问题描述】：

我正在研究 SQL 注入，并在我的 PHP 代码中尝试了这个查询：

$condition = str_replace(["'","\\"],["\\'","\\\\"], @$_GET['q']);
$query = "SELECT * FROM dummy_table WHERE dummy_column = '$condition'";

DB 和表字符集设置为 UTF8。

我不能注射任何东西，有人可以帮我吗？

编辑：正如 GarethD 所指出的，这将首先逃脱 ' 而不是 \，允许注入，那么这个 str_replace 呢？

$condition = str_replace(["\\","'"],["\\\\","\\'"], @$_GET['q']);

【问题讨论】：

使用准备好的语句/参数化查询有什么问题？
正如我所写的，我正在研究 SQL 注入，所以准备好的语句对我来说毫无用处。我需要一个易受攻击的查询来训练自己。我在开发时总是使用 PDO 和/或准备好的语句。请停止向我推荐其他缓解技术，并帮助我了解如何绕过此示例。
@BobJarvis 这取决于 $_GET['q'] 值，但每次我使用单引号时，它都会被翻译为 \'。如果我不能使用'？这应该是一个非常基本的示例，但我找不到漏洞。
@PeeHaa 结果总是空的，我不能让 mysql 抛出错误，你能给我一个 $_GET['q'] 抛出 mysql 错误的值吗？错误报告已启用并报告所有（包括通知）
你说过“DB and tables charset is set to UTF8”，但是the character set of the database connection呢？还有，你确定服务器的SQL模式不包含NO_BACKSLASH_ESCAPES？

【解决方案1】：

这个孤立的例子对注入是无懈可击的。

但您必须意识到防止 sql 注入 不仅仅是字符替换。情况可能与您目前认为理所当然的情况不同。因此，从长远来看，由于essential drawbacks of this method，您的代码会变得容易受到攻击：

字符替换本身并没有错，但仅当它用作完整格式化的一部分时；应用于正确的查询部分；由数据库驱动程序完成，而不是程序员；就在执行之前。

您在 cmets 中提出的功能是一个很好的步骤，但仍然不够，成为上述缺点的主题，使它们容易出现各种人为错误。

并且 SQL 注入不是这种方法的唯一问题，它也是一个可用性错误，因为这个函数会破坏你的数据，如果用作后期 magic quotes 的化身，或者使你的代码臃肿，如果用于格式化应用程序代码中的每个变量。

这样的函数只能用于处理占位符，当然不能使用自制的替换函数，而是数据库API提供的适当函数。

【讨论】：

最好解释一下这些基本缺点是什么。 OP 说他正在研究它，所以这对他（以及我们所有人）都会有好处
您的意思是，如果我使用类似 function safeString($val){ $val = str_replace(["'","\\"],["\\'","\\\\"], $val); return "'$val'"; } function safeInt($val){ return is_numeric($val) ? (int)$val : 0; } 的东西来转义任何字符串或整数，我将不会受到整数和字符串的 SQL 注入攻击？
当然我的函数是基于表列而不是用户输入调用的。我知道密码必须是字符串，所以我会使用 safeString 而不是 safeInteger。
@Your Common Sense 列出您谈论的那些“缺点”而不是简单地发布一般的 SQLi 文章会很有用。