本文分享的Writeup是作者在做Keybase.io的漏洞眾測(cè)中發(fā)現(xiàn)的SOP(同源策略)繞過(guò)漏洞，由于Keybase.io在用的多個(gè)API端點(diǎn)都啟用了CORS(跨域資源共享)機(jī)制，這種緩解同源策略的機(jī)制某種程度上克服了同源策略的嚴(yán)格限制，可以讓不同域服務(wù)器間實(shí)現(xiàn)交互請(qǐng)求。而作者在測(cè)試中發(fā)現(xiàn)了Keybase的CORS策略錯(cuò)誤配置，利用這種缺陷，可以操縱瀏覽器緩存獲取用戶敏感數(shù)據(jù)信息。一起來(lái)看看。

Keybase 是一個(gè)開(kāi)源的跨平臺(tái)即時(shí)通訊工具，在 PC 設(shè)備上支持 macOS、Linux 和 Windows 平臺(tái)，并提供 Chrome/Firefox 瀏覽器擴(kuò)展。此外還提供 iOS 和 Android 版本。和眾多 IM 工具相比，Keybase 最吸引人的地方在于免費(fèi)使用且不會(huì)受到任何廣告騷擾，最重要的是它還是一個(gè)開(kāi)源項(xiàng)目。

在安全性和隱私方面，Keybase 采用了端到端的加密方式，承諾會(huì)為每個(gè)用戶的群組、文件和聊天等數(shù)據(jù)提供安全保護(hù)。如果這些數(shù)據(jù)上傳到云中，也會(huì)進(jìn)行加密處理。

漏洞前言

Keybase在當(dāng)前用戶向其他用戶發(fā)送加密消息時(shí)，可以讓當(dāng)前用戶通過(guò)一個(gè)API接口去查找其他Keybase用戶，在該接口中提供了加密發(fā)送消息時(shí)所需的，如公鑰等其他Keybase用戶公共信息。這聽(tīng)起來(lái)貌似是安全的，是吧？

該API接口的CORS(跨域資源共享)策略配置如下：

Access-Control-Allow-Origin: *

Access-Control-Allow-Methods: GET

Access-Control-Allow-Headers: Content-Type, Authorization, Content-Length, X-Requested-With

Access-Control-Allow-Credentials: false

在了解這個(gè)CORS配置問(wèn)題之前，我們先來(lái)厘清幾個(gè)重要的知識(shí)點(diǎn)：

1、Access-Control-Allow-Origin中的星號(hào)“*”說(shuō)明，任意外部域名都能與該API進(jìn)行交互，執(zhí)行跨域的請(qǐng)求調(diào)用；

2、Access-Control-Allow-Credentials中的“false”說(shuō)明， 這里可能出于安全考慮，服務(wù)器不允許用戶在跨域請(qǐng)求中包含代表身份信息的Cookie。此處Access-Control-Allow-Headers暴露的用戶認(rèn)證頭信息和接下來(lái)要講的漏洞關(guān)系不大，因?yàn)樵诓樵兩鲜鯝PI接口中用不到。

漏洞情況

自然地，由于上述那個(gè)可查詢的API接口是公共的，所以在進(jìn)行跨域請(qǐng)求時(shí)無(wú)需攜帶防御CSRF(跨站請(qǐng)求偽造)的token信息，因?yàn)橛脩粼谑褂肒eybase.io時(shí)是經(jīng)過(guò)身份驗(yàn)證的，且他的會(huì)話信息存儲(chǔ)在了Cookie中，只有一些非常敏感的API接口會(huì)要求在請(qǐng)求頭中攜帶用戶認(rèn)證頭token。

后來(lái)我發(fā)現(xiàn)，如果在消息加密驗(yàn)證和發(fā)送環(huán)節(jié)，用上述那個(gè)查找其他Keybase用戶的API來(lái)查找我自己，哪怕輸入我名字中的一個(gè)字母，搜索結(jié)果中就會(huì)匹配到我的一些賬戶信息，其中竟然包含了我的一些敏感信息，如：

郵箱地址

我使用和剩余的邀請(qǐng)碼數(shù)量

計(jì)費(fèi)信息

上一次登錄的時(shí)間戳、郵件形式的時(shí)間/日期驗(yàn)證碼

TripleDes加密的PGP私鑰

但是，我并沒(méi)有私鑰存儲(chǔ)在Keybase上啊，之后我才了解到這是Keybase的在2015到2016年的一個(gè)遺留功能，現(xiàn)在已經(jīng)不再實(shí)施。

經(jīng)測(cè)試，一旦我在上述API請(qǐng)求中Cookie信息被刪除，我的個(gè)人敏感信息也不會(huì)再返回顯示。但是，我在服務(wù)端對(duì)該API的響應(yīng)消息中發(fā)現(xiàn)了一個(gè)名為 ‘Etag’ 的消息頭，這是一個(gè)瀏覽器緩存標(biāo)記頭，代表客戶端請(qǐng)求資源未發(fā)生變化，那么瀏覽器就可以從用戶的緩存內(nèi)容中去取出然后響應(yīng)給用戶。

Payload與漏洞利用

我想起Twitter用戶@Bitk_曾用過(guò)一個(gè)技巧，那就是用javascript的fetch API方法去強(qiáng)制從瀏覽器緩存中直接發(fā)起一個(gè)跨域請(qǐng)求，而恰巧 Keybase 在這里未曾對(duì)服務(wù)端響應(yīng)頭部署過(guò)任何緩存控制頭(Cache-Control)措施，于是，我就在本地構(gòu)造了如下的Payload

如果上述Payload請(qǐng)求能成功執(zhí)行，可能就會(huì)返回響應(yīng)一些Keybase的緩存信息，基于此，我執(zhí)行了一個(gè)身份驗(yàn)證請(qǐng)求，最終有效地返回了與我賬戶相關(guān)的一些個(gè)人敏感信息。如下：

為了確認(rèn)Payload是否被成功執(zhí)行，從下圖的瀏覽器請(qǐng)求信息中可以看到，fetch方法直接從瀏覽器緩存中讀取了我的身份信息。

漏洞上報(bào)及處理進(jìn)程

2019.12.19 ? 漏洞初報(bào)

2019.12.19 ? 兩小時(shí)后，Keybase在響應(yīng)消息中中加入了‘Cache-Control: no-store’

2019.12.24 ? Keybase獎(jiǎng)勵(lì)了$1,500 公布漏洞

*參考來(lái)源：enumerated，clouds 編譯整理，轉(zhuǎn)載請(qǐng)注明來(lái)自 FreeBuf.COM

精彩推薦

總結(jié)

以上是生活随笔為你收集整理的同源策略禁止读取位于_用浏览器缓存绕过同源策略（SOP）限制的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。