你说安全就安全？对红芯浏览器的一次安全测试

你说安全就安全？

近日，红芯浏览器“套壳”一事被网络舆论炒的沸沸扬扬。红芯浏览器被官方标榜为“安全、稳定、可控的企业浏览器”，其中“自主可控”一项已经被舆论所质疑，但是被官方放在第一项进行宣传的“安全”是否属实呢？ [好文分享：www.ii77.com]

据笔者所知，红芯浏览器的主要客户为国内政府、大型国有企业，单位主体的性质决定了其内部会有大量涉及商密、机密、甚至涉及国家安全的重要信息，而红芯浏览器则被设计为触及这些重要信息的媒介，如果它出了问题，那么后果不堪设想。 [原创文章：www.ii77.com]

为了验证红芯浏览器的安全性到底如何，小编决定做了一个简单的安全测试。对于这种套壳浏览器，安全测试大体可以分为两个部分，一个是“壳”的安全性，一个是浏览器“内核”的安全性。

对于“壳”，由于小编没有服务器环境，暂时无法接触到“壳”的主要逻辑，暂时作罢，如果你有测试环境，可以分享给小编，我们将在后续文章中分享测试结果。

图1 需要设置服务器地址才可以登陆，进而才可以测试“壳”

那么我们就测一下”内核”。根据之前网络上的爆料文章，红芯为了兼容XP，使用了最后一个兼容XP的内核：Chromium49。说起这个内核，笔者不禁回忆起了自己的青春，当初学编写chrome扩展的时候正是基于这个版本，说起来已经是两年前的事情了。

换句话说，如果你使用了两年前的版本，你失去不仅仅是两年内Chromium的新特性、新功能，更重要的是你失去了这两年内Chromium积累的安全补丁。

本次测试文件为红芯企业浏览器的3.0.54版本。

图2 红芯浏览器3.0.54安装文件

测试项目：XSS Auditor(filter) ByPass

XSS Auditor(filter)ByPass 翻译过来意思是：XSS审计器（或称XSS过滤器）的绕过。一直以来，XSS攻击是web前端领域里面威胁最大、利用最广泛的漏洞。在国际权威组织owasp针对最流行的Top10的web攻击统计中，XSS攻击从未掉队。

图3 2013-2017之间XSS的排名变化

然而，从这张图可以看到XSS从2013年的第3滑落到2017年的第7名，这其中的原因是多方面的，但其中重要的原因，就是现代浏览器引入并不断完善的XSS Auditor对反射型XSS的“狙击”，让XSS攻击越来越难用。

XSS Auditor最早被Chrome4、IE8引入。当然，道高一尺魔高一丈，XSS Auditor的更新不是闭门造车，而是在不断的攻防对抗中完善自己。全世界的黑客都在乐此不疲寻找XSS Auditor中的缺陷，以求绕过防护进行XSS攻击。而几乎Chrome的每次更新、IE的每个补丁，都会更新XSS Auditor，让这些绕过措施失效。然后黑客又找、官方又更新……由此往复循环，才有了今天较为完善的XSS Auditor防护体系。

我是不是扯远了。回到正题，红芯用了两年前的内核，那么意味着XSS Auditor已经两年没有更新，理论上这两年内的任何一个绕过XSS审计器的利用代码都是可以生效的。

我们先构造一个简单的反射形XSS漏洞：

我们检查红芯浏览器是否能抵御XSS攻击。地址栏输入：

输入的js并没有执行，可见红芯是开启了XSS Auditor的。

百度随手搜了一段绕过XSS Auditor代码，即在上面的js前面加一串%00。“%00”是16进制的0，在C语言中代表字符串的结束。不同的程序对0字符的理解不同，因此这个字符经常会引发一些安全问题。输入：

图4 绕过红芯的防护，执行了XSS

成功绕过XSS Auditor执行了js。

相同的代码在我的Chrome63（非最新）上却被成功拦截。

图5 该漏洞早已被谷歌官方修复

测试项目：UXSS

Same origin policy（同源策略，简称SOP）一直是web前端安全的基础。简单来说，SOP是指就是每个网站中的可执行脚本（包括html/js/flash等）只有读写自己网站内资源的权限，禁止跨域读写其它网站的内容。

举个例子，你同时打开了淘宝和京东的网站，淘宝和京东网站的js会同时在你的浏览器上运行。浏览器认为这两个网站是严格隔离的，淘宝的js不可能访问京东的收藏夹，同样，京东的js也不可能访问淘宝的购物车。这很好理解。

那么如果这种规则被破坏，后果则不堪设想。设想你访问某个网站，其中某个不知名的小广告商的js有权限访问你邮箱中的商业合同、你网盘中的私密照片，我就问你还敢不敢上网。

既然SOP这么重要，黑客又怎么可能放过呢。黑客们也在不断寻找绕过SOP的方法，这类绕过方法，或者说SOP的缺陷，被称为uxss漏洞。此类漏洞一旦被发现，基本上都被定性为高危漏洞。

图6和图7，谷歌高额悬赏uxss漏洞

与XSS Auditor一样，谷歌官方也不断修复着这些漏洞，而对于一个已经停止维护的内核，这类漏洞的PoC（即漏洞利用代码）在网上比比皆是。

在chromium项目的bug反馈页面，找到一个作用于chrome <52的UXSS。这个漏洞提交时间为2016年4月份。

http://bugs.chromium.org/p/chromium/issues/detail?id=604901

根据作者提供的Demo，把目标域名修改为baidu，把要执行的js修改为如下：

图8 修改跨域执行的js，效果为展示当前url并读取cookie

将Demo部署到本地http://127.0.0.1/中，用红芯访问。

图9 demo提供三种跨域方式分别为：跳转后执行、新标签页执行、iframe中执行uxss

点击第一个按钮，意为“跳转后执行uxss”，点击后调转至baidu，并以baidu域的权限执行了我们定义的js代码。

图10 以baidu的权限执行了js

上面的过程，演示了http://127.0.0.1/中的js读取了http://www.baidu.com/上的Cookie，Cookie意为着什么我就不多说了。换句话说，浏览器的SOP被破坏，http://127.0.0.1/将有权限读取 http://www.baidu.com/上的任何资源。如果进一步的利用，可以读取你百度搜索历史，百度网盘里的文件等等。

作为对比，我们换Chrome63试一下：

图11 漏洞已经修复

页面报错，代码没有执行。

解决方案

首先是对官方的建议，新内核不代表一定不会兼容XP。完全可以像360浏览器那样，把不兼容的函数一一手改成兼容的，当然这个工程量很大。

对于普通用户，尤其是政企类用户，在官方没有给出升级方案之前，暂时不建议使用。

后记

我从新审视了红芯官方对于安全功能的阐述，看上去很高大上。

图12 红芯主要对身份认证和通讯加密方面进行了介绍

红芯对于安全的宣传集中在身份认证和通讯加密，如果浏览器内核出了问题，导致浏览器被恶意代码接管，谈这些是没有意义的。

由于没有测试环境，对于这两点并没有测试，不过也没有必要了，毕竟决定你安全级别是木桶的短板。

安全不是销售的夸夸其谈，不是产品经理的纸上谈兵，不是投资人的患得患失，也不是程序员的“想当然”。安全是一件很专业的事情，应当交给专业的人去做。

*本文作者：山东星维九州安全技术有限公司，转载请注明来自FreeBuf.COM