昨日外媒针对中国的移动应用UC浏览器发布了一篇质疑报道,称其存在信息传输加密问题。针对文中提到的信息传输加密风险,记者对百度、腾讯、阿里等互联网公司的应用进行测试,结果发现该信息传输加密问题并非个案。百度、腾讯等都存在明文传输或加密级别不够等问题。

也就是说,国内的互联网厂商对于不涉及敏感信息的地理位置信息、设备信息等大多采用类似的传输加密方式,该国外机构的质疑一定程度上给中国互联网行业的移动应用信息传输加密通用标准提出了整体挑战。

以下是两大主流手机浏览器——腾讯手机QQ浏览器、百度手机浏览器的测试结果:

百度地图仅做简单加密,腾讯地图则根本未加密

百度浏览器的地图第三方SDK使用的是百度地图的网络定位服务。百度地图没有采用安全级别更高的HTTPS加密方式,只是在本地利用一个.so进行加密,便可在虚拟机上利用这个.so抓取Baidu的数据,如下图:

0522-ceshi1

0522-ceshi2

而QQ手机浏览器的地图第三方SDK使用的是腾讯地图的网络定位服务,腾讯地图在客户端采用的是明文存储(用户信息、时间、定位信息、POI信息等),情况,如下图:

0522-ceshi3

百度手机浏览器和QQ浏览器消息推送SDK都明文传输了IMEI等设备信息

针对手机浏览器使用的消息推送SDK进行分析,我们也能看到QQ浏览器在运行过程中将IMEI等设备信息明文传输到服务器。

我们进行简单分析:对QQ浏览器测试的机主的手机信息如下图:

0522-ceshi4

网络劫包工具抓取的QQ浏览器与http://wup.imtt.qq.com:8080的通讯请求post的数据体,该数据经过标准的url编码,解码后能清晰的看到用户imei等信息被明文发送到服务器。

QQ浏览器在传输过程中,IMEI等设备信息被明文发送到服务器,如下图:

0522-ceshi5

同样,在对百度手机浏览器使用的信息推送SDK进行分析后发现,其传输数据针对IMEI等信息只是做了倒序处理,基本没有加密作用。同时百度手机浏览器中用于URL的加密算法仍然是对称加密算法,是可以通过破解客户端来得到解密算法还原加密信息的。

用于分析百度浏览器的手机信息见下图:

0522-ceshi6

通过网络劫包工具抓取的百度浏览器与http://loc.map.baidu.com/sdk.php的通讯请求头发现,其POST的数据体虽然是加密的数据,但进行简单解密之后发现只是对关键信息做了一个倒序的处理,如下图:

0522-ceshi7

而且这个通讯请求得到的结果,是以明文回传的用户地址信息,如下图:

0522-ceshi8

手机百度浏览器、QQ浏览器的搜索关键词请求也都是明文传输

同时,记者对手机QQ浏览器、手机百度浏览器以及其默认使用的搜狗搜索和百度搜索的搜索关键词传输也进行了测试,结果发现搜索请求均采用了明文传输的方式。

手机QQ浏览器,默认使用搜狗搜索,在请求头里出现了搜索词,见下图:

0522-ceshi9

手机百度浏览器,默认使用百度搜索,在请求头里出现了搜索词,见下图:

0522-ceshi10

注:

针对此次国外人权机构提出的国内移动应用信息传输加密风险,是指中国主流的移动应用在使用一些第三方应用的SDK时,在涉及传输一些不敏感的地理信息及设备相关信息时,加密级别不够高,存在被攻破风险。

国内应用针对非敏感类信息基本未使用非对称加密算法(HTTPS),而是使用对称加密算法进行数据传输,当SDK被人逆向分析就会导致密钥泄漏。

IT耳朵微信号:erduomi