magic_quotes_gpc()的解毒剂? [英] Antidote for magic_quotes_gpc()?

问题描述

我已经看过几十个这样的PHP代码段:

I've seen dozens of PHP snippets that go like this:

function DB_Quote($string)
{
    if (get_magic_quotes_gpc() == true)
    {
        $string = stripslashes($string);
    }

    return mysql_real_escape_string($string);
}

如果我拨打DB_Quote("the (\\) character is cool");，会发生什么? (感谢jspcal！)

What happens if I call DB_Quote("the (\\) character is cool");? (Thanks jspcal!)

我们不是应该仅在get_magic_quotes_gpc() == true 和值源自$_GET，$_POST或$_COOKIE超全局变量时才去除斜线吗?

Aren't we supposed to strip slashes only when get_magic_quotes_gpc() == true and the value originated from $_GET, $_POST or $_COOKIE superglobals?

推荐答案

是的，我也看到过数十个类似的PHP代码段.有点可悲.

Yeah, I've seen dozens of PHP snippets like that, too. It's a bit sad.

魔术引号是一个输入问题.如果您需要让应用程序使用magic_quotes_gpc的古旧错误在服务器上运行，则必须在输入阶段通过迭代GET/POST/COOKIES数组并删除斜杠来解决该问题.一种简单的替代方法是检测魔术引号选项，并在设置时死于服务器糟透"错误.

Magic quotes are an input issue. It has to be fixed at the input stage, by iterating the GET/POST/COOKIES arrays and removing the slashes, if you need your app to run on servers using the foul archaic wrongness that is magic_quotes_gpc. The simple alternative is to detect the magic quotes option and die with a "your server sucks" error when set.

mysql_real_escape_string是输出问题.如果您不使用参数化查询(绝对应该考虑)，则需要在脚本之外，数据库内容的目录中运行它.

mysql_real_escape_string is an output issue. It needs to be run on the way out of the script, on content heading to the database, if you're not using parameterised queries (which you should definitely consider).

这是程序中两个独立的无关阶段.您不能将它们放在同一个函数中，尽管可能会尝试将所有字符串处理封装到一个框中，但这种方法很诱人.

These are two separate unrelated stages in the program. You can't put them in the same function, tempting though it may be to try to encapsulate all your string processing into one box.

难道我们不应该仅在值源自$ _GET，$ _ POST或$ _COOKIE超全局变量时才去除斜杠吗?

Aren't we supposed to strip slashes only when [...] the value originated from $_GET, $_POST or $_COOKIE superglobals?

是的，完全正确.这就是为什么您引用的代码段确实有害的原因.因为跟踪字符串的原点是不切实际的(特别是因为您可能组合了来自不同来源的字符串，其中一个被斜杠，另一个未被斜杠)，所以您不能在一个函数中做到这一点.它必须是在适当的时候调用的两个单独的字符串处理函数.

Yes, exactly. Which is why the snippet you quoted is indeed harmful. Because tracking the origin of a string is impractical (especially as you might combine strings from different sources, one of which is slashed and the other not), you can't do it in one function. It has to be two separate string handling functions called at the appropriate time.

这篇关于magic_quotes_gpc()的解毒剂?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！