我想拥有一个不连接数据库就表现为mysql_real_escape_string的功能,因为有时我需要在没有数据库连接的情况下进行干式测试。mysql_escape_string已被弃用,因此是不可取的。我的一些发现:
http://www.gamedev.net/community/forums/topic.asp?topic_id=448909
我想拥有一个不连接数据库就表现为mysql_real_escape_string的功能,因为有时我需要在没有数据库连接的情况下进行干式测试。mysql_escape_string已被弃用,因此是不可取的。我的一些发现:
http://www.gamedev.net/community/forums/topic.asp?topic_id=448909
Answers:
没有数据库连接就无法安全地转义字符串。mysql_real_escape_string()
并且准备好的语句需要连接到数据库,以便它们可以使用适当的字符集对字符串进行转义-否则,使用多字节字符仍然可以进行SQL注入攻击。
如果仅测试,那么您可能还可以使用mysql_escape_string()
,它不能100%保证不会受到SQL注入攻击,但是如果没有数据库连接就无法构建更安全的东西。
mysql_escape_string
没有连接(仍然试图找出原因)。由于该功能已被弃用,我只是想知道如何替换它。可以在不用打开连接的任何函数替换中指定“适当的字符集”,这显然是合理的。
好吧,根据mysql_real_escape_string函数参考页:“ mysql_real_escape_string()调用MySQL的库函数mysql_real_escape_string,它转义了以下字符:\ x00,\ n,\ r,\,',“和\ x1a。”
考虑到这一点,那么在您发布的第二个链接中给出的功能应该完全满足您的需求:
function mres($value)
{
$search = array("\\", "\x00", "\n", "\r", "'", '"', "\x1a");
$replace = array("\\\\","\\0","\\n", "\\r", "\'", '\"', "\\Z");
return str_replace($search, $replace, $value);
}
mb_strpos()
(并mb_substr()
创建类似于的行为substr_replace()
)这样做安全吗?
与我的其他答案完全相反,即使使用多字节字符,此后续功能也可能是安全的。
// replace any non-ascii character with its hex code.
function escape($value) {
$return = '';
for($i = 0; $i < strlen($value); ++$i) {
$char = $value[$i];
$ord = ord($char);
if($char !== "'" && $char !== "\"" && $char !== '\\' && $ord >= 32 && $ord <= 126)
$return .= $char;
else
$return .= '\\x' . dechex($ord);
}
return $return;
}
我希望比我自己更有知识的人可以告诉我为什么上面的代码行不通...
通过进一步的研究,我发现:
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-11.html
在多字节编码处理中发现了一个SQL注入安全漏洞。该错误位于服务器中,错误地解析了使用mysql_real_escape_string()C API函数转义的字符串。
Josh Berkus和Tom Lane发现并报告了此漏洞,这是OSDB联盟项目间安全合作的一部分。有关SQL注入的更多信息,请参见以下文本。
讨论。在多字节编码处理中发现了一个SQL注入安全漏洞。SQL注入安全漏洞可能包括以下情况:当用户提供要插入数据库的数据时,用户可能会将SQL语句注入服务器将要执行的数据中。关于此漏洞,当使用不支持字符集的转义(例如,PHP中的addslashes())时,可以绕过某些多字节字符集(例如,SJIS,BIG5和GBK)的转义。结果,诸如addslashes()之类的函数无法防止SQL注入攻击。无法在服务器端修复此问题。最好的解决方案是应用程序使用由mysql_real_escape_string()之类的函数提供的字符集转义功能。
但是,检测到MySQL服务器如何解析mysql_real_escape_string()输出的错误。结果,即使使用了字符集感知功能mysql_real_escape_string(),也可以进行SQL注入。该错误已修复。
解决方法。如果无法将MySQL升级到包含mysql_real_escape_string()解析中的错误的修复程序的版本,但运行MySQL 5.0.1或更高版本,则可以使用NO_BACKSLASH_ESCAPES SQL模式作为解决方法。(在MySQL 5.0.1。中引入了此模式。)NO_BACKSLASH_ESCAPES启用SQL标准兼容模式,其中反斜杠不被视为特殊字符。结果将是查询将失败。
要为当前连接设置此模式,请输入以下SQL语句:
SET sql_mode='NO_BACKSLASH_ESCAPES';
您还可以为所有客户端全局设置模式:
SET GLOBAL sql_mode='NO_BACKSLASH_ESCAPES';
通过使用命令行选项--sql-mode = NO_BACKSLASH_ESCAPES或通过在服务器选项文件中设置sql-mode = NO_BACKSLASH_ESCAPES(例如,my.cnf或my.ini),也可以在服务器启动时自动启用此SQL模式。 ,具体取决于您的系统)。(缺陷号8378,CVE-2006-2753)
另请参见Bug#8303。
NO_BACKSLASH_ESCAPES
引入其他漏洞。