字符编码带来的安全隐患——一个谷歌XSS漏洞

本文翻译自 http://shiflett.org/blog/2005/dec/googles-xss-vulnerability

多年以前谷歌曾爆出一个XSS漏洞证明了字符编码设置的重要性。

但直到2011年,这种漏洞还是时有发生。

一个典型的例子参见淘宝UTF7漏洞跨站注入漏洞:http://xiaohaizi.org/article/550.html


正文:

PHP 函数 htmlentities() 第三个参数声明了字符的编码:

(yukon12345:这个函数是过滤HTML特殊字符,转化成html编码字符集。比如’会转化为')

<?php 

$html = array(); 

$html['username']= htmlentities($clean['username'],

                                ENT_QUOTES,

                                 'UTF-8'); 

echo"<p>Welcome back, {$html['username']}.</p>"; 

?>


这个例子用了UTF-8,因此Content-Type header本来应该在服务器或HTML文档声明为

Content-Type:text/html; charset=UTF-8

 

有研究者用Watchfire 查看到谷歌并没有声明文字编码。同时他们也发现如果你用下面一个URL链接访问(这个链接并不存在)

http://google.com/url?EVIL

 

你会看到一个返回页面:

 

Forbidden

 

Your client doesnot have permission to get URL /url?EVIL from this server.

 

但谷歌并没有很好的处理含utf7编码的恶意提交。因为上面那个php过滤函数针对的是UTF-8。

同时由于谷歌没有在返回页面charset里声明编码方式,

如果使用IE浏览器,它会自动判断前4096字节的字符,找到UTF7编码的字符的话,IE将forbidden页面以UTF-7方式编码呈现。这样就绕过了谷歌的防XSS措施,导致敏感字符没有被过滤。

这个故事说明,你必须确保你转码程序和数据发送系统的编码一致性。

换句话说,

使用htmlentities()时保持编码一致性, 或者使用 mysql_real_escape_string() (取决于你的选择)

谷歌已经修复了这个漏洞。


yukon12345:外国人的找错方式真的很特别。另外这篇文章是2005年的了,翻译一下是因为我之后翻译的一本书里有提及字符编码的安全性。


阅读更多
想对作者说点什么? 我来说一句

<em>UTF</em>-7 编码解码工具

2018年05月07日 0B 下载

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭