如何判断手机浏览器是否有安全隐患？

桃扇骨 2022-08-05 04:20 335阅读 0赞

浏览器的安全其实是一个非常复杂的问题，它在很大程度上是由浏览器本身的定位决定的。举个例子，一个本来几乎拥有所有系统访问权限的APP，却要从鱼目混杂的互联网洋汪中去下载一个不知道谁写的页面+脚本，然后在本地运行，而为了安全起见，还要保证执行的脚本自动屏蔽掉那些不该看的、不该拿的东西。而且，拜device API （设备接口）所赐，网页脚本如需访问诸如摄像头、麦克风等很多敏感就需要相应的浏览器支持，于是浏览器也需要访问相应的device API 。

![556fc5481b159.jpg][]

**浏览器自身设计**

事实上，第一批浏览器， 比如 Internet Explorer, Opera, Firefox (Netscape), 在最初的设计的时候，都没有能预见到互联网会以如此爆发性的速度发展， 同时也受制于硬件条件的限制， 无一例外的采用单块结构（monolithic architecture)。所谓的单块结构，就是浏览器的每个模块，都塞在一起，而没有明确的隔离。 这种做法代码执行高效，写起来也很方便，不过现在看起来， 如果从安全的角度来讲，则是很有问题的。

![556fc58264cb7.jpg][]

要知道浏览器里面有非常多的模块， 有一些模块专门处理从网络上下载下来的内容， 比如文档解析器， 文档布局器，或者是Javascript的执行。 又有一些只和本地系统接口， 比如文件访问，密码的存储， 剪贴板一类的。 如果全都放在一起， 那简直就是给网上下载下来的恶意脚本开了一扇便利之门。 一个更好的架构是把这两组模块分别隔开。然后把第一组专门处理网络下载内容的模块用沙箱一类的技术装起来。   
  
现代的浏览器， 比如[谷歌][Link 1]的Chromium, 或者使用Chromium框架的浏览器（如桌面端猎豹和360）， Opera 桌面（版本12以后） 以及Opera mobile 一类的， 都是采用的这种结构，基本上可以把很多潜在的安全风险扼杀在摇篮之中。 （想了解详情的同学可以参考[这里][Link 2] ）

在这种比较干净的架构出来之前，各家浏览器基本上都是修修补补， 或者直接就是拿产品特性说事儿，比如Firefox说明自己比较安全的原因基本上是 ： 我的独立（没有和操作系统集成）， 也不像IE一样往死里做（不支持Active X 插件一类的奇葩东西）  具体可参见[这里][Link 3]

而Opera 在Presto 时代， 则在内部的代码规范里面明确规定任何情况下不能是用栈上缓存，从而杜绝当年极其流行的栈上缓存溢出攻击。

所谓栈上缓存，其实就是在栈上的存储区域。栈通常都是被调用时处于存储空间中，调用完毕立即释放。而栈顶的地址和栈的最大容量是系统预先规定好的，在 WINDOWS下，栈的大小是2M（也有的说是1M，总之是一个编译时就确定的常数），如果申请的空间超过栈的剩余空间时，将提示overflow。因此，能从栈获得的空间较小。

（关于栈上缓存，具体参考[这里][Link 4]）

到了手机浏览器时代，硬件和操作系统本身的安全性都加强了。 硬件方面从x86转到[ARM][], 天生就对栈上缓存溢出免疫。 基于\*nix 结构的iOS 和Android 自带沙箱结构，于是浏览器本身也被沙箱装了起来。 所以技术上来讲，由于多了两层壁垒，手机浏览器普遍要比桌面浏览器安全, 桌面浏览器上的那种首页书签搜索引擎各种被乱七八糟改的情况在手机浏览器上面基本看不到。 当然，国内大部分的手机浏览器还是单块结构，单块结构能有的问题一个也都没有少。 [Chrome][]/Opera mobile/ 欧朋X＋ 这种基于Chromium 架构的浏览器安全性相对来讲会好一些   
  
所以选择一个安全的手机浏览器其实没有那么复杂，国际一般比国内的在安全方面的意识要强一些。**大牌一点的浏览器在遇到通用性安全漏洞时 (比如上次著名的heart bleed漏洞）反应时间比小的浏览器厂商会快一些。   
  
浏览器和网站之间的数据传输**  
  
上面说谈的其实讲的都是浏览器如何面对网站上面的恶意代码保证自己不被黑掉。浏览器还有一块非常大的安全区域是在于数据传输。比如大家都不希望自己的银行密码被除了网上银行之外的其他人看到。   
  
3.15晚会里面的wifi钓鱼演示其实就是展示数据传输中数据被第三方窃取的可能性，这个可能是陈老湿们最不愿意看到的事情。浏览器的世界里面对于数据传输有两种主要的方式 ：  
HTTP （超文本传输协议） 和 HTTPS （安全传输协议).   
  
**其中 HTTP 与其说是不安全，不如说是令人发指的不安全。因为 HTTP 不仅仅是明文传输，而且是用文本来传输的，就是说，传输的报文，直接人就可以读得懂。**

比如：Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

这个是在HTTP里面发送给服务器用户名＋密码的报文( 来自于wikipedia ) 。

基本就是明晃晃的告诉别人，你看， 我的密码在这里哦，然后拿base64编了一下码，就发将在广袤的互联网上了。注意哦， 这个是编码不是加密，没有任何安全性可言的。

![556fc95639e59.jpg][]

HTTPS 会好非常多， HTTPS 的数据是加密传输，加密的强度也不小，很多银行都在使用，对于一般的攻击是免疫,。

当然 BOSS 级别的 NSA 不在此列, 因为HTTPS 虽然理论上不能破解，但是NSA丧心病狂的在HTTPS用的硬件随机发生器中植入了后门。 （详情参见[这里][Link 5]）

有一些浏览器。 比如 Opera Mini 或者带有 Opera turbo 技术的浏览器 提供端到端的私有加密。这一类的浏览器在安全性方面会有加分。

PS： 关于国内浏览器采集用户隐私数据问题(IMEI, IMSI)等。

多说两句这个， 作为国内App的从业人员，App（包括浏览器）采集IMEI， IMSI已经是一个非常普遍的现象，事实上，你其实很难找到不采集的APP, 想要知道一个APP是否采集IMEI, IMSI，只需要打开应用的权限管理，看看有没有这一项就可以了。

![556fc97655e2e.jpg][]

而这种行为，其实更多的是由国内的App推广市场的情况决定的，大部分APP（包含浏览器）对你的IMEI并没有多大兴趣，如果真的想要，混淆以后也能用。只是在国内的推广渠道里面，统计，对账的数据都是基于IMEI的。这个决定了大部分App如果想被推广，一定是需要采集IMEI的。并非是想采集用户隐私。   
  
当然地理位置数据采集就更普遍了，浏览器采集这个，其实很大程度上是为了支持[html5][] 中的Geolocation 组件，Chrome 也会采集。

![556fc989d7c4d.jpg][]

这个行为其实和你去银行开个信用卡， 银行会要你的身份证复印件是一样的道理， 这里面的安全问题不在于银行是否采集你的身份证复印件，而是采集完了以后，有没有能力或者意识把你的信息放在一个安全的地方。 而国内大部分App如果出了问题，都是出在数据保存上。选择的原则还是一样，尽量选者大的，安全记录好的公司。

[556fc5481b159.jpg]: http://leiphone.qiniudn.com/uploads/new/article/600_600/201506/556fc5481b159.jpg
[556fc58264cb7.jpg]: http://leiphone.qiniudn.com/uploads/new/article/600_600/201506/556fc58264cb7.jpg
[Link 1]: http://www.leiphone.com/tag/%E8%B0%B7%E6%AD%8C
[Link 2]: http://seclab.stanford.edu/websec/chromium/chromium-security-architecture.pdf
[Link 3]: http://website-archive.mozilla.org/www.mozilla.org/security/security/security-announcement.html
[Link 4]: http://en.wikipedia.org/wiki/Stack_buffer_overflow
[ARM]: http://www.leiphone.com/tag/arm
[Chrome]: http://www.leiphone.com/tag/chrome
[556fc95639e59.jpg]: http://leiphone.qiniudn.com/uploads/new/article/600_600/201506/556fc95639e59.jpg
[Link 5]: http://en.wikipedia.org/wiki/Bullrun_%28decryption_program%29
[556fc97655e2e.jpg]: http://leiphone.qiniudn.com/uploads/new/article/600_600/201506/556fc97655e2e.jpg
[html5]: http://www.leiphone.com/tag/html5
[556fc989d7c4d.jpg]: http://leiphone.qiniudn.com/uploads/new/article/600_600/201506/556fc989d7c4d.jpg