首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >匿名者如何使用UTF-16 ASCII来欺骗PHP逃逸?

匿名者如何使用UTF-16 ASCII来欺骗PHP逃逸?
EN

Security用户
提问于 2012-02-02 20:16:42
回答 3查看 13.4K关注 0票数 22

几个月前,匿名者使用SQL-injection关闭了一个儿童色情网站。我在这篇文章上读到,匿名者声称“服务器正在使用经过改进的PHP进行转义”,但是他们能够“用UTF-16 ASCII编码绕过它。”他们到底做了什么?我如何保护我的网站免受类似的攻击?

EN

回答 3

Security用户

回答已采纳

发布于 2012-02-04 03:39:38

首先,"UTF-16 ASCII编码“是一个矛盾,因为UTF-16和ASCII是相互排斥的编码方案。但他大概是指使用Unicode绕过过滤机制。

一般的原则是:我们经常想到用ASCII编码的字符-- "A“是数字65,"z”是数字122。但这并不是唯一的字符编码方案,因为世界上使用的不仅仅是英语字母,我们需要代表更多的字符。因此,Unicode在从僧伽罗语到克林贡语的每一种语言中都有几乎每一个字符的表示。

表示所有这些字符(大约。一个数字形式的110万可能,并非全部使用)是一个真正的挑战。您可以使用32位,但这是浪费空间,因为4个字节中的3个通常为零。您可以使用可变长度,但是不能执行常数时间子字符串操作。因此存在许多标准,其中之一是UTF-16 (您可能猜到它使用了16位字符)。

并不是所有的程序员都习惯于处理多个字符集的想法,尽管底层框架通常会支持这些字符集。因此,有时过滤规则或预防措施将建立在假设字符将表示在UTF-8或ASCII,而他们通常是。

因此过滤器寻找一个给定的字符串,例如\",它在ASCII和UTF-8中对应于模式{92,34}。但是在UTF-16中,它看起来是不同的;它实际上是{0,92,0,34},这是不同的,可以通过一个没有预料到的过滤器滑动。

虽然过滤器不理解UTF-16,但底层框架理解它,所以内容与任何其他内容一样得到规范化和解释,从而允许查询继续未过滤。

编辑以添加:

请注意,PHP在处理字符编码方面非常差;如果有的话,那就是低估了问题。默认情况下,PHP将所有字符串视为ASCII,这意味着内部函数(如strstrpreg_replace )只是假定所有字符串都是ASCII编码的。如果这听起来是危险的不足,那是因为它是。但是在他们的辩护中,请记住PHP比UTF-16早了大约一年,所有这些都应该在PHP 6中修复。

同时,创建了mbstring库来解决这一不足,但它既没有被广泛部署,也没有得到充分利用。如果您幸运地拥有了这个扩展,您可以在您的mbstring.overload文件中使用php.ini文件来强制将内部字符串处理函数替换为多字节感知的替代方法。这也可以使用php_admin_value指令在您的.htaccess文件中激活。

另一个有用的函数是mb_内部_编码,它设置PHP内部用来表示字符串的编码。通过使用与unicode兼容的内部编码,您可能会减轻一些缺点。至少有一个我读过的引用(但不幸的是现在找不到)表明,通过将内部编码设置为UTF-8,您可以对入站字符串启用额外的处理,从而将它们规范化为单个编码。另一方面,至少有一个其他引用表明,PHP在这方面的行为尽可能愚蠢,只是简单地拒绝修改数据,而不管其编码如何,并允许您处理后果。虽然前者更有意义,但根据我对PHP的了解,我认为后者同样有可能。

作为最后一种选择,我只在开玩笑中提到了这一点,那就是不要使用PHP,而是采用设计得更好的体系结构。很难想出一个像PHP一样具有许多基本问题的流行框架。语言、实现、开发团队、插件体系结构、安全模型-- PHP如此广泛的部署真是令人遗憾。当然,这只是一种观点。

票数 27
EN

Security用户

发布于 2012-02-05 09:46:21

我不知道这是否是匿名者使用的方法,但是请看一下http://bugs.mysql.com/bug.php?id=22243

看来Connector.Net (MySQL的托管.Net驱动程序)中有一个错误。从链接错误报告中:

.net字符串是以UTF-16编码的.字符串被转换为Windows1252 (SBCS编码),以便通过网络发送,在此转换过程中,可能尚未检查的unicode字符将“变成”单引号。

bug报告接着列出一个包含问题Unicode字符的字符串,并说:

具体来说,在第二个字符串中,问题引号是unicode字符8242 ("\u8242")。当服务器接收到此字符串时,引用将是一个单引号(ASCII 96)并中断查询,并可用作sql注入攻击。

链接错误在2009年被标记为一个固定错误的复制,但完全有可能被利用的服务器运行的是一个较旧版本的MySql,存在此问题。

票数 4
EN

Security用户

发布于 2012-02-05 12:20:05

只是胡思乱想。它们可以在UTF-16中编码ASCII字符串,这样,可能用来检查危险用户输入的例程就会被愚弄/绕过。然后对字符串进行解释,恶意输入没有被过滤。

这听起来像是开发人员使用了不安全的编码实践,或者有些库/应用程序已经过时,因此很危险。这不像匿名黑客/脚本有任何绕过魔法,这都是关于实验。

大多数情况下,如果他们有0天或一些新的技术来破解所有的东西,他们不会让人们知道这一点。由于一些程序员/管理员的无能,他们经常使用老的学校技术。安全很重要。

票数 0
EN
页面原文内容由Security提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://security.stackexchange.com/questions/11391

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档