Haulyn5 的博客
0%

Som19 论文阅读笔记

发表于 更新于 分类于 阅读次数： Valine：

前言

上一篇论文用了前前后后 4 天 才将阅读笔记做完，而且还是在 中间部分跳过了一部分内容的情况下，效率还有提高的必要，不然恐怕面试前连 2019 年的 S&P 的都刷不完。不过之后的论文的阅读策略可能会比较偏重于了解基础和背景（因为底子太弱了），学习写作和做研究的手法技巧，例如上一篇能好好的理解一下HTTPS 和 PKI 等也很不错了，至于论文内部实施的一些具体细节如果感觉有些过于高大上或者没必要细读可能就会直接跳过。

下一篇的 Paper 题目为 EmPoWeb: Empowering Web Applications with Browser Extensions ，令我注意的是这篇 paper 的作者只有 1 人诶，好强。

过了一遍摘要，又是一个做 Extension 的文章，大致内容是 Web Application 收到的约束比较多，遵守SOP（同源策略），但是 Extension 受到的约束较少，尤其令人印象深刻的是与上一篇做 extension 的论文一样用到了 elevated 这个词哈哈哈。

Browser extensions are third party programs, tightly integrated to browsers, where they execute with elevated privileges in order to provide users with additional functionalities.

Abstract 第一句

然后问题出在 Web Application 与 Browser Extensions 之间的通信信道，Web Application 借由 Browser Extension 的 API，可以做到 bypass SOP, 获取其他 Web Application 的用户数据，用户凭证（cookies），浏览历史，书签，已安装的 Extension，Extension 的存储，在用户设备下载并保存任意文件。

正文

初读的问题

这篇论文做了什么？做到什么程度？怎么做的？

本篇论文作者检查了大量的 Browser Extensions，并且发现相当多的 Extensions 存在消息传递的漏洞可被 Web Applications 利用，实施多种恶意行为。最终得到了一份具体的数据与 Extension 的 List，给出了一种针对插件漏洞的插件代码静态检测工具。具体过程见方法论部分。

什么是 Web Application ？ 举例？ Chrome APP 和 Web Application 是一样的吗？

初读此文时，看到 Web Application 时不由得疑惑，因为前一阵子看上一篇 Extension 的 paper 时，就遇到了 Chrome APP 这个字眼，而且最后找到了 Chrome 官方的消息，确定在前几年 Chrome 已经停止了 Chrome APP，鼓励 APP 迁移 Extension。具体原因个人猜测可能是为了整合，并且 Extension 有多家浏览器统一的标准 API，可能便于开发者在多浏览器中以较小的改动发布插件。

https://chrome.google.com/webstore/category/apps 这里是当使用 Google 搜索 “ Chrome Apps” 后的第一条结果，当进入时会被自动重定向至 https://chrome.google.com/webstore/category/extensions 。

此外，在 https://developer.chrome.com/apps/about_apps 也可以看到显眼的通告如下：

Important: Chrome will be removing support for Chrome Apps on all platforms. Chrome browser and the Chrome Web Store will continue to support extensions. Read the announcement and learn more about migrating your app.

https://developer.chrome.com/apps/about_apps

再看一部分，就知道作者口中的 Web Application 另指他物，这里的 Web Application 值得应当是一些 Web 的具体的应用，例如 Gmail 邮箱，一个 Blog （比如你正在看的），以这种方式理解，作者所指的 Web Application 应该是覆盖了绝大多数网站的网站服务，此外作者在摘要中提到， Web Application 遵循 SOP （ Same Origin Policy），即同源策略。这个之后可能会再发博客介绍一下。

所以综上， 二者应当是完全不一样的。

初读

这篇文章的主要工作在于研究了 Web Application 和 Extension 的通信机制，由于 Web Application 受到了较多的安全约束，如 SOP 等，而 Extension 由于是用于丰富用户浏览体验，所以自然权限较高，约束较少。既然两者能通信，是否意味着 Web Application 能借由 Extension 执行一些自己不能执行的事情呢？

于是本篇 paper 的威胁模型便是 敌手是一段 正在浏览器中运行的 Web Application 中出现的 Script ， 注意 Web Application 本身有可能并非恶意，但是很多 Web Application 用到了第三方代码，其安全性难以保证。敌手目标为通过与 Extension 的交互获取用户隐私。而具体执行的内容则取决于攻击的 Extension 的权限。作者对这些攻击进行了分类如下。（其实上文也有提及）

  1. Execute Code : 任意代码执行（以 Extension 的权限）
  2. Bypass SOP：敌手借由 Extension 的权限 发起跨源请求（ Cross Origin Request），达到不被 SOP 约束的目的。
  3. Read Cookies ： 借由 Extension 读取 Cookies，这个就很可怕了，可以做会话劫持，或者单纯读取隐私。
  4. Trigger Downloads：可以在无需用户做任何操作的情况下进行下载。
  5. Read browsing history, bookmarks and list of installed extensions：获取用户兴趣习惯，侵害隐私。可以用于用户追踪。
  6. Store Data：可以在 Extension 的存储空间存取信息，以用于用户追踪等目的。而且用户在清空 Web Application 之后仍然能得到保留。

而 paper 中具体使用的一些通信的 API 这里就不搬运了，还有一些 Extension 相关的知识的话在之前做插件的一篇中有做过一些整理，之后会发到博客上。

接下来的部分包括一些具体实施的方法和结果的数据，主要内容为搬运了。

方法

作者收集了来自 Chrome ， Firefox ， Opera 的 78315 个插件。经过 静态分析 和 手工复核 两步得出结论。

静态分析

作者使用 JavaScript 编写了一个静态分析工具，用以初步判断 Extension 的风险，减少手工工作量。

It has been fully written in JavaScript, using various Node.js packages. We used Esprima [31] and Recast [32], for parsing and manipulating JavaScript abstract syntax trees (AST), and Jsdom [33] for parsing HTML.

Esprima 是一款 ECMAScript parser ， 由 JavaScript 写成。 而 ECMAScript 是一项关于 JavaScript 的标准，很多时候二者语义相同。链接 ： https://esprima.org/

后面的两个库就扔一下链接吧…… 目前的 JavaScript 水平甚至有点无法理解功能，

https://www.npmjs.com/package/recast

https://www.npmjs.com/package/jsdom

施工中……