mysql_escape_string漏洞 [英] mysql_escape_string vulnerabilities
问题描述
最近我正在向我的朋友解释参数化及其优点,他问它在安全性方面比mysqli_escape_string
有什么优势.具体地说,您能想到尽管输入字符串被转义(使用mysqli_escape_string)仍能成功执行SQL注入的任何示例吗?
I was explaining parametrization and its advantages to my friend recently, and he asked how it was any better than mysqli_escape_string
in terms of security. Specifically, can you think of any examples of SQL injection that would succeed despite the input strings being escaped (using mysqli_escape_string)?
更新:
很抱歉,我的原始问题不够清楚.这里要问的一般问题是,尽管转义了输入字符串,是否仍可以进行SQL注入?
I apologise for not being clear enough in my original question. The general question being asked here is, is SQL injection possible despite escaping input strings?
推荐答案
更新的答案
(在发布我的答案之后)已对问题进行了编辑,以专门针对mysqli_escape_string
,这是mysql_real_escape_string
的别名,因此考虑了连接编码.这使得原始答案不再适用,但为了完整起见,我将其保留.
Updated answer
The question was edited (after my answer was posted) to specifically target mysqli_escape_string
, which is an alias of mysql_real_escape_string
and therefore takes the connection encoding into account. This makes the original answer non-applicable anymore, but I 've left it for completeness.
简而言之,新的答案: mysqli_escape_string
和参数化查询一样,在安全性方面都很好,只要您不自欺欺人.
The new answer, in short: mysqli_escape_string
is as good security-wise as parameterized queries, provided you don't shoot yourself in the foot.
具体而言,PHP上的巨大警告中突出显示了您不得做的事文档页面:
Specifically, what you must not do is highlighted in the giant warning on the PHP doc page:
字符集必须在服务器级别或使用 API函数
mysqli_set_charset()
对其影响mysqli_real_escape_string()
.
The character set must be set either at the server level, or with the API function
mysqli_set_charset()
for it to affectmysqli_real_escape_string()
.
如果您不注意此警告(即,如果使用直接的SET NAMES
查询更改字符集) ,则可以将字符集从单字节编码更改为方便" (从攻击者的角度来看)多字节编码,您实际上已经模仿了哑巴mysql_escape_string
的作用:尝试转义字符而不知道输入所使用的编码.
If you don't heed this warning (i.e. if you change the character set with a direct SET NAMES
query) and you change the character set from a single-byte encoding to a "convenient" (from the attacker's perspective) multibyte encoding, you will have in effect emulated what the dumb mysql_escape_string
does: attempt to escape characters without knowing which encoding the input is in.
这种情况使您可能容易受到SQL注入的攻击,如以下原始答案所述.
This situation leaves you potentially vulnerable to SQL injection as described by the original answer below.
重要说明::我记得读过某个地方,最近的MySql版本已经在其末端(在客户端库中)填补了这个漏洞,这意味着您可能是完美的即使使用SET NAMES
切换到易受攻击的多字节编码也很安全.但是请不要相信我.
Important note: I remember reading somewhere that recent MySql versions have plugged this hole on their end (in the client libraries?), which means that you might be perfectly safe even if using SET NAMES
to switch to a vulnerable multibyte encoding. But please don't take my word for it.
与mysql_real_escape_string
相比,裸露的mysql_escape_string
没有考虑连接编码.这意味着它假定输入实际上是单字节编码,而实际上可以合法地是多字节编码.
In contrast to mysql_real_escape_string
, the bare mysql_escape_string
does not take into account the connection encoding. This means that it assumes the input is in a single-byte encoding, when in fact it can legitimately be in a multibyte encoding.
某些多字节编码具有对应于单个字符的字节序列,其中字节之一是单引号(0x27
)的ASCII值;如果输入这样的字符串,mysql_escape_string
将很乐意转义引号",这意味着将0x27
替换为0x5c
0x27
.根据编码规则,这可能导致将多字节字符变异为另一个包含0x5c
的字符,并将剩余" 0x27
作为独立的单引号保留在输入中. Voilà,您已经在SQL中注入了未转义的引号.
Some multibyte encodings have byte sequences that correspond to a single character where one of the bytes is the ASCII value of the single quote (0x27
); if fed such a string, mysql_escape_string
will happily "escape the quote", which means substituting 0x27
with 0x5c
0x27
. Depending on the encoding rules, this could result in mutating the multibyte character into another that includes the 0x5c
and leaving the "remaining" 0x27
as a stand-alone single quote in the input. Voilà, you have injected an unescaped quote into the SQL.
有关更多详细信息,请参见此博客文章.
For more details see this blog post.
这篇关于mysql_escape_string漏洞的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!