PHP magic_quotes_gpc 漏洞

发布于 2024-08-18 23:23:52 字数 442 浏览 4 评论 0原文

我被分配到公司的一个遗留 Web 应用程序，经过一两天的研究源代码，我发现了一个类似于以下内容的 SQL 注入向量：

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

我尝试对此执行 SQL 注入测试，但由于 PHP 的 magic_quotes_gpc 模块已打开，因此失败。

我知道 magic_quotes_gpc 是脏，但我们有数百行（如果不是数千行）与上面的代码类似的代码。我们根本无法关闭 magic_quotes_gpc ，因为这会让这样的代码很容易受到攻击。

我想知道上面的代码有多“可利用”，以及我们是否应该立即修复它，或者将修复它的任务与我们的其他重构任务一起包含在内。

原文

I've been assigned to one of my company's legacy webapps, and after a day or two of poking around the source, I've found an SQL injection vector similar to the following:

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

I've tried to perform an SQL injection test against this, but it fails, due to PHP's magic_quotes_gpc module being switched on.

I know magic_quotes_gpc is dirty, but we have hundreds - if not thousands - of lines of code similar to the one above. We simply can't afford to switch magic_quotes_gpc off, as this would leave code like this wide open to attack.

I'd like to know how 'exploitable' the code above is, and whether we should fix it immediately, or include the task of fixing it in with our other refactoring tasks.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

眼趣 2024-08-25 23:23:52

将站点从 magic_quotes_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_quotes_gpc 错误的真正原因：它正在将输出级编码应用于输入级。

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

The usual way to transition sites away from magic_quotes_gpc is to add a wrapper function:

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'])."'");

This will fix the problem of addslashes not being character-set-aware that can cause it to be vulnerable in some cases, and will generally make the code continue to ‘work’ as before.

However in the long term relying on input-escaping is unsustainable, as it will multiply slashes into input strings you are not inserting into the database, and fail to escape strings you're inserting into the database from other sources. This is the real reason magic_quotes_gpc is the wrong thing: it's applying an output-stage encoding to the input stage.

So add the wrapper function and then slowly go through updating all the SQL interpolations to use it. When you've got them all you can turn the magic quotes off.

回复收藏 0 原文