卡巴斯基安全浏览器_一年三番五次修，卡巴斯基为何依然无法完美修复杀毒软件中的这些洞 （技术详情）？...

  聚焦源代码安全，网罗国内外最新资讯！ 编译：奇安信代码卫士团队 卡巴斯基 web 防护功能将拦截广告和追踪器，警告用户关于恶意搜索结果等等。但这个功能在浏览器中运行而且需要和主应用程序通信。要确保这种通信的安全性，必须要回答的问题是：它把通向王国的钥匙放在了哪个地垫之下？ 本文作者Wladimir Palant 详细分析了自己向卡巴斯基从该功能中找到的多个漏洞，这里说明的是其中一个。 奇安信代码卫士翻译如下：

概述

2018年12月，我可以证实，多个网站能够劫持卡巴斯基浏览器脚本与其所有配置中主应用程序之间的通信。 网站从而能够以多种方式操纵该应用程序，包括禁用广告拦截和追踪的防护功能。 卡巴斯基当时表示会在2019年7月份解决这些问题。 但进一步调查发现他们只限制了更为强大的 API 调用，而任何网站仍然可以访问大量应用程序。 更糟糕的是，卡巴斯基发布的新版本泄露了大量用户系统信息，如卡巴斯基程序的唯一标识符，同时还引入一个新问题，可导致任意网站触发应用程序崩溃，使得用户系统无法得到病毒防护功能的保护。

问题为何如此复杂？

杀毒软件通常通过浏览器扩展实现 web 防护措施，这样使得和主应用程序的通信更加方便快捷： 浏览器扩展可使用易于保护的本地消息传递机制 (native messaging)。 原生应用程序内置多种安全预防措施，指定了哪些浏览器扩展可以与其连接。 但我们这里考虑的环境不仅仅是浏览器扩展。 如果用户拒绝安装卡巴斯基的浏览器扩展，那么卡巴斯基软件不会轻易放手，而是会直接将必要脚本注入所有的网页。 这种做法甚至适用于 HTTPS 网站中，因为卡巴斯基为了操纵所有的网站不惜突破 HTTPS 连接。 另外，更特别的是 IE 浏览器插件。 由于IE 浏览器并不会提供适当的扩展 API，其插件限制将脚本注入网页中。 虽然它并不要求操纵网页的源代码，但脚本仍然会在这些页面上下文中执行且不会具备任何特别权限。 因此，卡巴斯基这样做的目的似乎是为这三种环境提供和卡巴斯基应用程序统一的通信方式。 但在其中两种环境中，卡巴斯基的脚本所具有的权限和已被注入脚本的网页的权限完全一样。 那么如何阻止网站连接到使用同样方式的应用程序呢？ 现在知道这个任务的挑战性有多大了吧？

卡巴斯基的解决方案

卡巴斯基的卡法人员显然给出了一种解决方案，不然我也不会写这么一篇文章了。 他们决定在应用程序和脚本(他们在代码中称之为“signature”)之间共享一个秘密。 在建立连接时，必须提供这个秘密值，而本地服务器只有在收到正确的值之后才会响应。 那么，扩展和脚本如何才能知道这个秘密是什么？ Chrome 和火狐浏览器使用本地消息传递机制进行检索。 至于IE 浏览器扩展和直接被注入网页中的脚本在这里变成该脚本的一部分源码。 由于网站受制于同源策略无法下载该源码，因此它们无法读取该秘密，至少从理论上来讲是这样的。

提取秘密

2018年12月，当我查看 Kaspersky Internet Security 2019 产品时发现它们的 web 集成代码在所有的环境中都在泄露该秘密(CVE-2019-15685)。 不管你是用的是什么浏览器，也不管是否安装了浏览器扩展，所有的浏览器都能够提取到和卡巴斯基主应用程序进行通信所需的秘密。 从注入脚本提取 入之前说书，如果没有浏览器扩展，那么卡巴斯基软件将直接把脚本注入到网页中。 由于 JavaScript 是高度动态化的执行环境，因此几乎可任意遭操控。 例如，网站可以替代 WebSocket 对象并看到脚本和本地服务器之间建立连接。 当然，卡巴斯基的开发人员也想到了这种场景，于是他们确保自己的脚本会在网站脚本之前运行。 同时还复制了 WebSocket 对象并且仅使用该对象。 但这种方法并非滴水不漏。 比如，网站仅能保证再次执行相同的脚本，但这次是在受操控的环境中执行。 虽然需要脚本 URL 才能这么做，但是它可以自行下载并从响应中提取该脚本 URL。 如下是我的方法：

fetch(location.href).then(response => response.text()).then(text =>{  let match = /