PHP magic_quotes_gpc漏洞

我被分配到我公司的一个传统Web应用程序中，在对源代码进行了一两天的探索后，我发现了一个类似于以下内容的SQL注入向量：

mysql_query("SELECT * FROM foo WHERE bar='" . $_GET['baz'] . "'");

---

我曾尝试对此执行SQL注入测试，但失败了，因为PHP的

magic\u quotes\u gpc

模块被打开

---

我知道

magic\u quotes\u gpc

是肮脏的，但我们有数百行（如果不是数千行的话）类似于上面的代码。我们根本无法关闭

magic\u quotes\u gpc

，因为这会让这样的代码容易受到攻击

---

我想知道上述代码的“可利用性”，以及我们是否应该立即修复它，或者将修复它的任务与我们的其他重构任务结合起来。

从

magic\u quotes\u gpc

转换站点的通常方法是添加一个包装函数：

function m($s) {
    if (get_magic_quotes_gpc())
        $s= stripslashes($s);
    return mysql_real_escape_string($s);
}

mysql_query("SELECT * FROM foo WHERE bar='".m($_GET['baz'])."'");

这将解决

addslashes

无法识别字符集的问题，该问题在某些情况下可能会导致其易受攻击，并且通常会使代码像以前一样继续“工作”

---

但是，从长远来看，依赖输入转义是不可持续的，因为它会将斜杠乘以未插入数据库的输入字符串，并且无法从其他源转义正在插入数据库的字符串。这是真正的原因

magic\u quotes\u gpc

是错误的：它将输出阶段编码应用到输入阶段

---

因此，添加包装器函数，然后缓慢地更新所有SQL插值以使用它。当你拥有了所有这些后，你可以关闭魔法引号。

只要魔法引号是打开的，并且你没有使用一些特殊的字符编码，可能会漏掉一些东西，你就应该没事了——可以这么说。问题是，无论出于何种原因，如果magic quotes不处于活动状态（服务器更改、配置更改），您都会有很多漏洞需要修复。

我会在开头添加一行，确保magic quotes已启用，如果在服务器配置中禁用，也会启用。然后你会或多或少地安全。

被否决——他不会完全安全，见Bobince的答案——他会或多或少地安全——正如我所说。不，他不会或多或少地安全，他会陷入一种虚假的安全感。更不用说魔法引号是阿萨德的巨大痛苦，当然，如果您知道这一事实，为什么在输入阶段所有值都被转义是如此糟糕？在我看来，magic_quotes_gpc是不好的，只是因为你没有完全意识到这一点。最初的发问者提到他需要修补数千行代码，我猜他不会问他是否能负担得起你提出的更改。为什么不在主代码入口处过滤所有输入参数（$\u GET、$\u POST、$\u REQUEST等）？因为在输入阶段，您不一定知道某个特定输入是否会进入SQL字符串文本，是否会直接输出到HTML，是否会放入发送的电子邮件，是否会与从数据库获取的另一个字符串进行比较，用于类似查询，或许多此类或其他查询。要使其正常工作，您必须记住哪些字符串中包含SQL转义，并为每个操作添加一个unescape，而不是将每个属性放入SQL字符串文本中。这比执行SQL查询时的转义要麻烦得多，因为SQL查询至少停留在一个位置。

magic\u quotes\u gpc

也不好，因为

addslashes

完全不是SQL转义的正确函数：在MySQL中存在多字节编码问题，在其他使用ANSI标准字符串文字而不是反斜杠的数据库中，它什么也做不了。所以，在使用神奇引号时，上面的查询不可能被黑客攻击？