本文叙述的是作者发现谷歌浏览器Chrome阅览辅佐插件（Read&Write Chrome extension）1.8.0.139版别同源战略（SOP）绕过缝隙的进程。该缝隙在于Read&Write插件短少对正常交互网页恳求源的安全查看，导致恣意网页都能够调用Read&Write插件的后台特权页面API来履行多种存在危险的操作。因为该版别插件的在线下载使用量较大，在缝隙上报前估量有八百万用户受到影响。
缝隙介绍
比方，使用名为 “thGetVoices”办法的后台API调用办法，能够用插件履行一个恣意URL链接的检索，并用postMessage办法来进行呼应通讯。经过这种办法的API歹意调用，攻击者能够绑架Read&Write插件去读取一些歹意且未经验证的会话数据。
作为验证，作者在文末制作了一个缝隙使用PoC视频，在安装了存在该缝隙的Read&Write插件之后，在进行使用操作时，能够使用缝隙长途读取到用户的Gmail邮箱地址信息。在缝隙上报之后，Read&Write插件开发方Texthelp公司敏捷修正了缝隙，并于第二天释出了更新补丁。现在，新版别的Read&Write插件已不存在该缝隙。
缝隙剖析
Chrome的Read&Write插件使用名为“inject.js”的Google浏览器内置脚本（Content Script）来向比如Google Docs在内的各种在线文档页面刺进一个自界说工具栏，以便利读者用户能够使用该插件进行文档读写。默许情况下，此脚本将会向一切HTTP和HTTPS源履行刺进，插件的使用说明中已界说了这一点：
...trimmed for brevity...
  "content_scripts": [
    {
      "matches": [ "https://*/*", "http://*/*" ],
      "js": [ "inject.js" ],
      "run_at": "document_idle",
      "all_frames": true
    }
  ],
...trimmed for brevity...
在  “inject.js” 脚本文件中，存在一个事情监听函数addEventListener，任何被刺进 “inject.js” 脚本文件的交互网页，假如以“postMessage”办法向插件发送呼应音讯，都能被该函数捕获到：
window.addEventListener(“message”, this.onMessage)
这个addEventListener函数还会调用另一个名为“this.onMessage”的函数，该函数用于处理恣意发往页面窗口的postMessage音讯：
function onMessage() {
    void 0 != event.source && void 0 != event.data && event.source == window && "1757FROM_PAGERW4G" == event.data.type && ("connect" == event.data.command ? chrome.extension.sendRequest(event.data, onRequest) : "ejectBar" == event.data.command ? ejectBar() : "th-closeBar" == event.data.command ? chrome.storage.sync.set({
        enabledRW4GC: !1
    }) : chrome.extension.sendRequest(event.data, function(e) {
        window.postMessage(e, "*")
    }))
}
postMessage() 办法：window.postMessage() 办法能够安全地完成跨源通讯。一般，关于两个不同页面的脚本需求具有同源战略才干通讯。window.postMessage() 办法被调用时，会在一切页面脚本履行结束之后（e.g., 在该办法之后设置的事情、之前设置的timeout 事情,etc.）向方针窗口派发一个 MessageEvent 音讯。 该MessageEvent音讯有四个特点需求留意： message 特点表明该message 的类型； data 特点为 window.postMessage 的第一个参数；origin 特点表明调用window.postMessage() 办法时调用页面的当时状况； source 特点记载调用 window.postMessage() 办法的窗口信息。
在上述代码中，能够看到onMessage()会把一切接收到的postMessage音讯经过“chrome.extension.sendRequest”办法发送到Read&Write插件的后台页面。别的，对这些音讯的呼应将传递回onMessage()函数，然后再经过其传递回Web页面中去。这个进程，实际上就在正常的Web拜访页面和Read&Write插件后边之间形成了一个署理机制。
从Read&Write插件的使用说明中，能够发现Read&Write插件中存在许多后台页面：
...trimmed for brevity...
"background": {
  "scripts": [
    "assets/google-analytics-bundle.js",
    "assets/moment.js",
    "assets/thFamily3.js",
    "assets/thHashing.js",
    "assets/identity.js",
    "assets/socketmanager.js",
    "assets/thFunctionManager.js",
    "assets/equatio-latex-extractor.js",
    "assets/background.js",
    "assets/xmlIncludes/linq.js",
    "assets/xmlIncludes/jszip.js",
    "assets/xmlIncludes/jszip-load.js",
    "assets/xmlIncludes/jszip-deflate.js",
    "assets/xmlIncludes/jszip-inflate.js",
    "assets/xmlIncludes/ltxml.js",
    "assets/xmlIncludes/ltxml-extensions.js",
    "assets/xmlIncludes/testxml.js"

[1] [2] [3]  黑客接单网