最近关于字符编码绕过PHP的addslashes功能再注入的漏洞被一些安全人员抓的满天飞，仔细追朔一下的话，可以发现，国外的一些安全人员在一年前、两年前已经研究的比较深入了。如下就是kuza55朋友在一年前发的文章。后来我发现许多朋友对这个漏洞理解的不是很准确，你可以测试一下如下网站：http://hackme.ntobjectives.com/sql_inject/login_addslashes.php。这里是一个专门针对addslashes功能进行的一个模拟测试，如果能够得到提示"Welcome Admin"的话，说明你攻击成功了。答案可以在本文的最后找到 ；）

另外，是否使用了Magic Quotes GPC 就一定安全呢？看过如下文档便知道了：http://www.webadepts.com/showthread.php?p=31

from: http://kuza55.blogspot.com/2007/06/mysql-injection-encoding-attacks.html

Early last year Chris Shiflett and Ilia Alshanetsky published some posts about how it is possible to conduct SQL Injection attacks against sites which escape user input, but either use an encoding unaware escaping function (e.g. addslashes()), or do not inform their escaping function about the issue.

I'm not going to re-hash their posts, so you should go read them now, if you haven't done so before.

But who actually does either of those things? Well, Google Code search reports approximately 54,300 results for applications using addslashes() and approximately 100 applications which have the words "SET CHARACTER SET" in their code.

Not particularly many of the latter, but the very first result is the rather popular phpMyAdmin project, so its not a completely unused query.

Anyway, since I hadn't seen any research on which character sets were vulnerable (and which characters to use), I wrote a small fuzzer to test all the character sets which MySQL supports (other than UCS-2), for several different encoding attacks, though only the ones described by Chris and Ilia yielded any results. Here are the character sets vulnerable, and the first character of the multi-byte sequence where \ is the second character:

• big5, [A1-F9]
• sjis, [81-9F], [E0-FC]
• gbk, [81-FE]
• cp932, [81-9F], [E0-FC]

I didn't successfully test ucs2 because ucs2 is a fixed width 2 byte character encoding, which will not execute queries passed in standard ascii, and so it would be impossible to get a webapp working if you set your connections to ucs2 but didn't convert all your queries, etc, so a configuration issue like that would be instantly noticed, and if you were using an encoding unaware function, then it would definitely be vulnerable, since all byte sequences are two bytes.

Anyway, if anyone is interested, I uploaded the fuzzer here: http://mihd.net/pwe0f9. As you will notice, I ripped the code which Ilia used to illustrate the vulnerability for GBK, so the two pieces look very similar. Its also not very well written, but it worked and got the results for me.

Notes: Part 2 of the fuzzer is trying to see if its possible to have a double or single quote as the second character in a multi-byte sequence, and Part 3 is trying to see if its possible to use a quote as the first character.

Also, this is obviously MySQL specific, the reason for this is because (as far as I could find out) MySQL is the only RDBMS which allows you to set the connection encoding through a query, all the other require configuration changes, and while addslashes() issues are applicable to all RDBMS's, most applications these days use mysql_real_escape_string().

测试页面的正确访问方法：http://hackme.ntobjectives.com/sql_inject/login_addslashes.php?username=%bf%27%20or%201=1/*