美国成人网站使用 WebSocket 绕过广告屏蔽插件

阅读数:7197 2016 年 11 月 8 日

话题:语言 & 开发架构

现在网络上的广告真的是无所不用其极,在网上冲浪,稍不留神,随时随地都会碰上广告,于是广告屏蔽这个需求,就应运而生了。古语云,道高一尺魔高一丈。今天这篇文章就介绍了 BugReplay 是如何发现美国成人网站 Pornhub 使用 WebSocket 绕过广告屏蔽插件。

这篇文章的本意并非是如何绕开广告屏蔽机制,而是用户了解情况后,在如何反制广告商上缩短探索的时间。

这篇文章重现了 BugReplay 的工程师发现美国成人网站是如何使用 WebSocket 绕过广告屏蔽插件的过程,视频演示可在此处观看。

当构建BugReplay的原型时,BugReplay 的工程师评估了 Chrome 捕捉和分析网络流量的不同方法。第一个就是看起来很有前途的chrome.webRequest API。

它的文档有如下的说明:

“使用 chrome.webRequest API 来观察和分析流量,并拦截、阻止或修改请求。”

这似乎正是 BugReplay 需要的。

在使用 Chrome webRequest API 进行实验后,该工程师很快意识到有一个大问题。它不允许用户分析任何 WebSocket 流量,而这个功能是用户真正需要的东西。

BugReplay 发现 2012 年有一个相关的 bug 报告:

“chrome.webRequest.onBeforeRequest 不拦截 WebSocket 请求。”

在这份 Bug 报告中,用户抱怨未能阻止 WebSockets,以致网站可以轻易的绕过广告屏蔽插件。如果 WebSocket 数据通过 webRequest API 对 Chrome 扩展不可见,没有一些重型攻击他们不能被屏蔽。

最初,理论上屏蔽广告似乎是有风险的。采用这种技术的网站的案例非常模糊。在 2016 年 8 月,一位来自拥有 Pornhub.com(MindGeek)的公司的员工,开始反对Chrome API 添加 WebSocket 屏蔽功能。依照 Alexa 的数据,Pornhub 是互联网上第 63 个访问量最大的网站。BugReplay 检查了几个 MindGeek 的网站,果不其然,他们发现,即使已经安装 Adblock Plus 插件,也能看到这些来自 MindGeek 所属的广告网络中的 Pornhub 广告,被标识位“垃圾广告”。

在下面的截图中,你可以在网页顶部看到一个横幅,表明该网站已发觉用户使用了广告屏蔽插件,并邀请用户订阅该网站的免广告高级版。在网页的右侧你能看到广告。

他们是如何做到的?

当用户访问 Pornhub.com 时,它会尝试检测您是否有广告屏蔽插件,如果检测到一个,它就打开一个 WebSocket 连接,作为传递广告的备份机制。

查看 BugReplay 浏览器记录,你可以看到多个网络触发请求,被 AdBlock 阻止了:它们在网络流量中被标记为“失败”,如果你单击详细信息中的一条,你能看到失败原因是:net::ERR_BLOCKED_BY_CLIENT. 这是 Chrome阻止资源加载时报告的错误。

你可以在网络面板中单独找到 WebSocket 框架,或者只查看WebSocket 创建请求。WebSocket 连接的域名是:“ws://ws.adspayformy.site.” ,这不过是针对广告屏蔽插件的玩笑而已。

当 WebSocket 加载时,浏览器为每个可用于广告的点发送一个带有 JSON 编码有效载荷的帧。检出一个WebSocket 框架,你可以在框架数据中看到广告数据被返回:

  1. zone_13,JavaScript 应放置广告。
  2. media_type的图像,让页面知晓用哪种元素来创建(大多数是视频广告,在这篇文章我选择了一张图像,因为这样相对温和)。
  3. 图像本身是 base64 编码的,因此可以使用data uri scheme来重建。
  4. 一个“img_type”(“image/jpeg”)通过 data uri。

广告屏蔽插件主要是用 webRequest API 进行工作的,因此通过在 WebSocket 上利用 base64 编码来传输数据构建广告,是一个绕开广告屏蔽的相当聪明的方式。

下一步是什么

2016 年 10 月 25 日,在 Chromium Tracker 上,一名贡献者写了一个补丁,增加了使用 webRequest API 来阻止 WebSockets 的能力。如果这个补丁被接受,将会集成到 Chrome stable 版。

广告屏蔽插件作者可以选择在何时或何时推出最新版本的 Chrome 浏览器,以便让内容提供商(如 Pornhub)了解他们在广告屏蔽战争中的下一步行动。

更新

自从 BugReplay 开始研究这个技术时,AdBlock PlusuBlock Origin已经发布解决方法来阻止这种技术,而AdBlock和其他人还没有。

对于 AdBlock Plus而言,包装器在发送 / 接收 WebSocket 消息之前执行虚拟 Web 请求。扩展将这些虚拟 Web 请求识别为表示 WebSocket 消息。如果应该阻止相应的 WebSocket 消息,它就拦截并阻止它们。然后 WebSocket 包装器基于虚拟 web 请求是否被阻止来决定允许 / 阻止 WebSocket 消息。

对于 uBlock Origin 来说,他们发布了一个解决方法,具有“使用 CSP 指令来屏蔽 WebSocket 的能力”。


感谢徐川对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。