字符编码带来的安全隐患——一个谷歌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年的了，翻译一下是因为我之后翻译的一本书里有提及字符编码的安全性。