瀏覽器漏洞挖掘思路

前言

最近被運維吊打了，之前開發的時候點被遺漏。今日早讀文章由@Masato Kinugawa分享。

正文從這開始～

在 Web 安全中，服務端一直扮演著十分重要的角色。然而瀏覽器的問題也不容小覷，它也會導致信息泄露等諸如此類的問題。然而許多人還沒有意識到瀏覽器對於安全的重要性。在這篇講座（文章）中，我們會給讀者帶來挖掘瀏覽器漏洞的思路。

挖掘漏洞的思路

確定目標

我們先來看看瀏覽器的大概結構：

DOM 解析 （HTML, XML, SVG, MathML, XUL）

腳本處理 （JavaScript, VBScript, asm.js, WebAssembly）

協議支持 （HTTP, FTP, WebSocket, HTTP/2, QUIC, DNS, mDNS, WebRTC）

媒體流支持 （JPG, GIF, PNG, WebM, Ogg, AAC, MP3, MP4, FLAC）

包含的中間件（Skia, ffmpeg, ICU, NSS, OpenVR, libpng, sqlite）

各種 API（Fetch API, Push API, Extension API, Fullscreen API, Web Speech API）

UI 組建（Location Bar, History, Bookmark, Context Menu）

安全功能（SOP, XSS Filter, CSP, SRI, TLS, Mixed Content, HSTS, HPKP, CT）

便利功能（Chrome Extension, Reading View, Secret Mode）

其它

我們應該如何從諸多功能中選取攻擊目標？這時，我們可以這樣入手：

檢查新功能

剛剛公布的功能往往沒有被太多的人研究，因此更有可能存在潛在的隱患。因此，我們可以試著在下列產品挖掘漏洞：

Firefox Nightly

Chrome Dev, Canary

Safari Technology Preview

Edge的最新版本

更新時，我們最好注意一下它們的發行日記或者開發者的 blog。這樣我們可以在最短的時間內得知新加入的特性。

Firefox 在該版本中提供了 link 預載入，這看上去十分有趣!這時，白帽子們可以以此功能為基礎，對其進行安全檢測，或者思考能否用它擴展供給面。

這是能讓我們獲取一手消息的相關平台：

檢查冷門的老功能

這些功能常常不被人們重視：

非標準化功能

冷門功能

常規插件

同樣地，我們也可以通過發行記錄，或者從已有的研究報告中來探索這些功能。

打個比方：

我用 dialogArguments/returnValue 時，發現數據可以傳輸到任意窗口，此處是否有 SOP 繞過漏洞呢？

在用 Dailog 時，用戶不能操作其它窗口，這有沒有可能引發 UI 相關的問題呢？

枚舉法 — 延伸已經存在的漏洞

我們可以去挖掘一下常見機制的問題：

JavaScript 的 HTTP 通信機制（sendBeacon，Fetch，Worker）

瀏覽器彈窗機制（alert，confirm，getUserMedia）

MIME 類型（text / javascript, image / svg + xml, application / octet-stream ...）

研究已經被列為高危的功能也很奏效：

windows 對象

HTTP 泄露

HTML5 Security Cheatsheet

通過枚舉法，我們能更好地集中到有效目標上。比方說：

在這裡，我們可以得知IE可以運行 CSS 里的腳本，這是否意味著我們可以用它來進行 XSS 或者過濾器繞過呢？

從 commit 歷史中挖掘漏洞

我們可以通過 git 歷史來發現有趣的特性，比如說：

對移動系統的支持（3d Touch, Spotlight, Universal Links)

正在完善中的功能（Web App Manifest, Geckoview)

那麼，我們如何發現值得關注的點呢：

已經被開發者標明為高危的功能

實現複雜的第三方庫(SQLite, Alamofire)

我們再來看個例子，這是一個 Chrome 的 commit 記錄：Https://goo.gl/xo6MMV

在 commit 之前，chrome 並沒有對國際化字元進行一個良好的處理，以下圖片的 a 實際上是Cyrillic 字符集的 U+0430（並不是英語的 a0）:

而:則是 U+0589，/是 U+2215

我彙報了這個問題，不過谷歌的解決方法是簡單粗暴地禁用國際化域名。

這個 commit 記錄則增加了兩個潛在的攻擊點：

用 SQLite 存儲數據是否意味著有 SQL 注入？

將變數插入到頁面中時候會導致 XSS?

當瀏覽器的一個功能有如下特點時，就往往意味著該功能有問題：

將 URL 給 API，它會返回特定的標誌

CSP 運行異常

你能發送任意 header 給一個目標

如果你知道要攻擊的具體目標，那麼你可以檢查：

location 返回的值

函數的行為

CSP 實現是否正確？

尋找字符集漏洞

通過瀏覽器對字符集處理的不當，我們可以挖掘許多問題。

各個瀏覽器對字符集的支持：

比方說 CVE-2013-5612，當你在 POST 請求中不指定字符集，那麼它就會默認使用上一個被指定的字符集。我們可以利用支持上的差異性來達到繞過 XSS Auditor

尋找第三方庫的漏洞

在 Pwn2Own 比賽中，來自長亭科技的研究人員成功地利用 SQLite 的內存損壞攻破了 Safari。同理，我們也可以在下面的lib中尋找漏洞：

其它攻擊面

瀏覽器解析特殊協議（比如 about）也可能產生種種問題。當我們在 firefox 輸入about:neterror?e=nssBadCert&d=Hello%20Guys!時，會有：

不忘學習前人經驗

在我們找漏洞的同時，不要忘記學習前人的思路，我們應該多想想這些問題：漏洞是什麼類型的？他們是怎麼找到漏洞的？這個漏洞又為何出現的？

我們可以通過 Security Advisor（mozilla，chrome），以及私人 blog 來學習尋找漏洞的過程。

深入研究目標

為了深入探索一個目標，我們需要了解一下特性：

這個功能是用來幹什麼的

如何使用它

輸入和輸出是什麼

有沒有什麼過濾

我們能否利用它繞過安全機制

我們能否用它攻擊安全站點

那麼，我們應該用什麼手段去深度挖掘呢？

親自使用一遍

審計代碼

審計可執行文件（反彙編）

查看軟體 log

就拿 Fetch API 來說：

fetch( http://api.example.jp/path ,{//我在這裡能代入哪些地址？

method: POST ,//我還能添加哪些方法?

headers:{

Content-Type : text/plain //這裡是否能插入其它header或者MIME類型?

},

body: Hello World! //body能插入哪些文字?

}).then(function(res){

console.log(res.headers.get( Content-Type ));//我能讀取哪些header的值?

}).catch(function(err){

console.error(err);//拋出的錯誤時候包含了敏感信息?

});

一個通過逆向找漏洞的例子：

edge 的一個 dll 包含了 XSS 過濾器的正則表達式，我們通過反向推導，或許可以找出 bypass payload。

探索有趣的行為

當我們發現了一些異常行為時，我們需要繼續留心，因為這往往意味著更深層次的漏洞：

跳轉後，地址欄不更新 (URL Spoof)

某個輸入導致瀏覽器崩潰或者暫停響應

HTML tag 不正常運行

文字亂碼

挖掘這類漏洞有什麼技巧呢？我們可以通過檢查如下功能：

URL scheme (http:, https:, ftp:, data:, resource:, about:, chrome-extension:)

Request method (GET, POST, HEAD, OPTIONS, TRACE)

瀏覽器怎麼輸出相關信息 (iframe, object / embed tag, svg foreignobject, Reading View)

瀏覽器怎麼獲取資源(img標籤, video/audio標籤, Worker的importScripts)

打開新 URL 的方法(Location頭, meta刷新, window.open, 瀏覽器的返回鍵)

非常規輸入（過長的字元串，HPP，空值，過大的數字，負數）

枚舉各種其他元素

來快速發現可能的隱患。

舉幾個例子：

在 CVE-2017-7789中，如果 firefox 在響應中收到多個 HSTS 頭，那麼 HSTS 就不會被啟用。這時只要攻擊者在普通的 HTTP 響應中包含幾個 HSTS 頭，那麼他/她就可以繞過 HSTS 機制。

而在CVE-2015-4483里,我們在`feed:`後添加 URL，就可以繞過 Content Mixed Blocker

漏洞利用

當你找到一個漏洞後，你應該如何利用它呢：

想像如何在現有 Web 應用中利用

因為這一漏洞，我們可以攻擊原本安全的網頁

這個漏洞會導致瀏覽器安全機制失效

就算不能在某些場景利用，你也要考慮可以利用它的理想環境

如果這個網站是這樣（設想狀態）實現的，那麼我們可以如何如何（攻擊）

如果這個設想相對靠譜，那麼該漏洞可能在特定環境有效

讓我們來看看 firefox 插件的一怪異行為，雖然我們可以利用該漏洞對頁面的 title（標籤頁的標題）進行 HTML 注入，然而由於 CSP，我們並不能觸發 XSS。

當我們仔細觀察%TITLE%，%CONTENT%的順序後，就會發現一個模板注入漏洞：

這樣的話，只要我們插入 form 元素到%TITLE%時，即使不能 XSS，也能外帶%CONTENT%給攻擊者。

在實際情境中，許多網站會將用戶輸入插入到頁面 title，就拿 Google 來說：

然而獲取別人的搜索結果似乎沒什麼卵用，我們是否能得到更敏感的資料呢？

Gmail 似乎是一個不錯的目標，我們可以發送一封惡意郵件給目標，當他/她展開該郵件時，頁面 title 會更換為郵件標題：

當用戶點擊 Click Me 時，郵箱信息就會被傳送給攻擊者

至此，我們成功地將該漏洞變廢為寶。

關於本文

作者：@Masato Kinugawa

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！