保护浏览器帮助程序对象

Question

我目前正在构建浏览器帮助程序对象。

BHO必须做的一件事是制作绕过跨域政策的跨网站请求。

• 为此，我公开了一种在内部使用__MyBHONameSpace.Request的{​​{1}}方法。

• 然而，我发现任何正在使用我的BHO的人现在都有一个CSRF漏洞，因为智能攻击者现在可以从我客户的计算机发出任意请求。

有没有聪明的方法来缓解这种情况？

Answer 1

完全防范此类攻击的唯一方法是将页面JavaScript的执行上下文与扩展程序的JavaScript代码分开。

当我研究这个问题时，我发现Internet Explorer确实提供了一种方法来实现这种上下文的创建，即通过IActiveScript。我没有实现这个解决方案，原因如下：

1. 缺少将IActiveScript与BHO结合的文档/示例。
2. 对未来缺乏确定性（例如https://stackoverflow.com/a/17581825）。
3. 可能的性能影响（IE因其卓越的性能而闻名，每个页面的两个JavaScript引擎实例如何影响浏览速度？）。
4. 维护成本：基于非常合理的假设，我已经有一个运行良好的现有解决方案。因为我不确定替代方法（使用IActiveScript）是否无障碍且面向未来（见2），我决定放弃这个想法。

我所做的是：

1. 接受非常坚定的攻击者将能够访问（部分）我的分机的功能。
   • @Benjamin询问对永久存储API的访问是否会对用户的隐私构成威胁。我认为这种风险是可以接受的，因为存储配额是强制执行的，并且所有存储的数据在使用之前都经过验证，并且它不会给攻击者提供任何攻击用户的工具。如果攻击者想要通过持久存储跟踪用户，他们可以在某个域上使用localStorage，并使用postMessage API通过<iframe>与此域通信。这种方法适用于所有浏览器，而不仅仅是安装了我的BHO的IE，所以当有一种方法已经适用于所有现代浏览器时，任何攻击者都不太可能花时间对我的BHO进行逆向工程以使用API​​（IE8 + ）。
2. 限制扩展程序的功能：
   1. 只应在需要激活的页面上激活扩展名。这大大减少了攻击面，因为攻击者更难以在https://trusted.example.com上运行代码并欺骗用户访问https://trusted.example.com。
   2. 在扩展级别（在BHO内的本机代码（例如C ++）中）创建并强制实施列入白名单的URL以进行跨域访问。
   3. 对于敏感API，请将其暴露于一小组可信URL（同样，不是在JavaScript中，而是在本机代码中）。
   4. 处理跨域功能的扩展部分不与Internet Explorer共享任何状态。 Cookie和授权标头将从请求和响应中删除。因此，即使攻击者设法访问我的API，由于缺少会话信息，他们也无法冒充其他网站的用户。
      这不能防止使用请求者的IP进行身份验证的站点（例如Intranet站点或路由器），但正确实施白名单已经涵盖了此攻击媒介（参见步骤2）。

“在本机代码中强制执行”并不意味着“本机代码中的硬编码”。您仍然可以提供包含元数据和JavaScript代码的更新。 MSVC ++（2010）支持ECMAScript样式的正则表达式<regex>，这使得实现基于正则表达式的白名单非常容易。

如果您想继续使用IActiveScript，可以在源代码ceee，Gears（已停止使用）或任何其他尝试增强的项目中找到示例代码IE的脚本环境。