Page 205 - 《软件学报》2021年第8期

罗武 等:浏览器同源策略安全研究综述 2487

(2) 安全威胁与应对
postMessage 在 2007 年被提出时,仅仅提供了一个参数来传输要发送的消息内容.Barth 等人 [59] 发现了
postMessage 无法满足机密性要求.如图 8(a)所示,受害者网页内嵌了一个第三方网页,并使用 postMessage 来传
输数据,该数据可能是用户的隐私数据.例如,受害者网页可能借助第三方网页来验证用户口令强度,此时的用
户口令将使用 postMessage 的方式传输给第三方网页.在这种情况下,攻击者诱导用户访问其网页,该网页内嵌
了受害者网页,进而内嵌了第三方网页.由于第三方网页为攻击者网页的孙子网页,攻击者网页可以对第三方网
页进行导航(修改 window.location.href 变量),导致浏览器将第三方网页重新加载为攻击者网页(如图 8(b)所示).
此时,受害者网页通过 postMessage 发送的秘密数据将被重新加载后的攻击者网页所接收,导致秘密数据泄漏.
这种针对 postMessage 机密性的攻击成功的原因在于,浏览器未考虑第三方网页被重新加载为攻击者网页.
Barth 等人 [59] 建议 postMessageAPI 增加第 2 个参数,用来表明发送方预期的接收方的源.当浏览器将受害者发送
的秘密数据提交给第三方网页时,浏览器判断第三方网页是否仍然属于原来的源.在图 8 的攻击中,由于第三方
网页被重新加载,其源变化为攻击者网页,导致浏览器对源的判断失败,浏览器将拒绝向该攻击者网页转发原来
的消息,从而攻击者无法获取到受害者网页的秘密数据.HTML 标准据此对 postMessageAPI 进行了修改而引入
了第 2 个参数,目前,浏览器已经能够抵抗图 8 所示的攻击.

攻击者网页 攻击者网页
受害者网页 postMessage(secret) 受害者网页 postMessage(secret)
第三方网页 攻击者网页

(a) 受害者网页往第三方网页发送 secret (b) 攻击者替换第三方网页来偷取 secret
Fig.8 Attacks on the confidentiality of postMessage communication mechanisms
图 8 针对 postMessage 通信机制机密性的攻击

在此之后,Son 等人 [14] 发现了使用 postMessageAPI 的另一个安全威胁.postMessage 涉及到消息发送方与接
收方,接收方需要验证消息是否来自于合法的发送方;否则,恶意的消息发送方(攻击者网页)能够通过消息来在
接收方(受害者网页)实现数据注入攻击.例如,当接收方网页将消息中的某些字段写入 cookie 时,攻击者可以通
过消息来篡改接收方网页的 cookie 内容;当接收方网页将消息中一些字段利用 JavaScript 提供的 eval 等 API
来当成代码执行时,攻击者可以在受害者网页中执行任意代码.HTML5 标准中明确指出,消息接收方需要判断
发送方的源 [91] .然而,Son 等人 [14] 对现有的 Alexatop 10000 网页进行了调研分析,发现现有网页中存在不足.
• 2 245 个网站上使用了 postMessageAPI;1 585 个网站没有对发送方进行验证.
• 261 个网站对发送方的源进行了验证,但是验证方式是不安全的.例如,有网站对发送方判断的代码为
if(m.origin.indexOf(“sharethis.com”)!=−1),这使得任意在源中含有 sharethis.com 的网页发送的消息都
会被接收方所接受,此时,攻击者可以通过注册类似于 sharethis.com.malicious.com 或者 evilsharethis.
com 等域名来发起攻击.
• 在未对发送方源进行验证或进行不安全验证的网站中,84 个网站允许攻击者网页在接收方网页执行
任意代码,或者往本地存储中注入任意内容.
针对这一类安全威胁,Son 等人 [14] 提出了两种防御方式:第 1 种方式要求发送方与接收方事先构造某个秘
密数据,由于同源策略限制,使得只有与发送方具备相同源的网页能够访问这个秘密数据,接收方消息处理函数