magic_quotes_gpc会救我吗?

时间:2012-11-15 11:32:53

标签: php escaping magic-quotes-gpc

通过执行特定任务,我被要求帮助(丑陋)项目。 问题是,我对网站中的其他文件没有任何控制,更不用说服务器配置了。我将要使用的一些数据来自这样的查询:

'SELECT * FROM table where value like "'.$unsafe.'"';

$ unsafe 是来自$ _POST或$ _GET的非转义值。 我检查了服务器,是PHP5.1.6并且有magic_quotes_gpc On所以数据正在自动转义。 这个查询是否易碎?冒号之间不安全给我的印象是它不能被打破,但也许我错过了一些东西。 我知道magic_quotes_gpc因其不安全性而被弃用,所以我很关心它,不是因为应用程序安全性因为我自己的知识而失败。

编辑:我知道* magic_quotes_gpc *的安全隐患,我从不在自己的项目中使用它。 总是使用参数化查询来避免注入,但这次我被要求在朋友/客户端项目中添加一个非常具体的代码,所以我无法改变已经完成的工作。我想知道是否有一个特定的值可以用来创建一个注射器,所以我可以说明我的朋友为什么要改变它。

2 个答案:

答案 0 :(得分:1)

如果DB是mysql而是使用mysqli_real_escape_string(),如果PHP版本很旧,你可以使用mysql_real_escape_string(目前不推荐)。

即使变量在冒号之间也可以注入,你只需要关闭变量值内的冒号然后注入你想要的任何东西。

答案 1 :(得分:1)

关于你的编辑:你问“我想知道是否有一个特定的值我可以用来创建一个注射器,所以我可以说明我的朋友为什么要改变它。”

根据manual page for mysqli_real_escape_string(),它逃脱的字符如下:

NUL (ASCII 0), \n, \r, \, ', ", and Control-Z.

旧的mysql_real_escape_string()函数也会转义相同的字符。

这为您提供了一个起点,可以使用哪些字符在MySQL中进行注入攻击。魔术引号只能逃脱引号字符和斜线字符,这显然会留下几个可以被利用的漏洞。

在一个简单的世界中,上述信息足以让我们通过对剩余的非转义字符进行字符串替换来修复转义。

但是,real_escape函数也需要一个活动的数据库连接才能使它们工作,这导致我们进一步复杂化:字符集。

如果数据库具有与PHP不同的字符集,则可能会发生进一步的攻击,尤其是使用可变长度字符集(如UTF-8或UTF-16)。

知道(或可以猜测)PHP和数据库正在使用的字符集的攻击者可以发送精心设计的注入攻击字符串,其中包含PHP看不到需要转义的字符,但这仍然会导致成功攻击MySQL 。这就是real_escape函数需要访问数据库才能知道如何进行转义的原因。

更多资源:

我希望能给你一些指示。