對於那些熟悉現代廣告技術的人來說，iFrame Busters是託管在發佈商網站上的HTML文件，允許廣告創意擴展到其標準邊界之外。這些可展開的廣告素材通常很容易在網站上識別,就是我們深惡痛絕的廣告塊。

蟲蟲看考有關文獻發現很多Busters中存在這樣或者那樣的XXS漏洞，本文就跟大家一起來截些廣告Busters的實現以及XSS漏洞解析。

互聯網廣告行業比較分散，各廣告供應商之間的流程可能差別很大。雖然對廣告網絡投放的完整說明超出了本文的範圍，但是基本流程都是通過iFrame和iFrame Busters來實現可擴展廣告素材展現。

例如，在發佈商頁面上提供的簡單（非擴展）廣告素材源碼如下所示：

請注意，iFrame的src屬性指向嵌入所需廣告素材的廣告客戶的域。這裡沒什麼特別的。這正是任何其他外部指向iFrame的功能。此外，請注意iFrame的大小限制為300*250，標準廣告位的大小。廣告不能將顯示擴展該框架的限制大小之外，由於同源策略（SOP）設置不能在其母頁面中做DOM操縱。

為了解決這個問題並允許特定廣告供應商繞過同源策略限制，通常會提供供應商iFrame Busters（特殊的HTML文件）以託管在網站的網站發佈域的主機上。

一個簡單典型的iFrame Buster（buster.html）可能如下所示：

這樣上面的iFrame Buster頁面就可以得以嵌入網站正常頁面（index.html）如下：

我們可以從上面的源碼中看到，在第3步（Step 3）中嵌入初始廣告的iFrame會重定向到buster.html文件所在的站點域。然後，buster文件可以訪問重定向URL中提供的參數來引用針對特定廣告展示的行為。

如上所述，由於iFrame Busters位於特定供應商的。這意味著可能會要求給定的網站託管大量第三方HTML文件以支持可擴展功能。

事實上，截止最近Google還在提供了一個多廣告供應商的iFrame Buster套件，可以在DoubleClick 的AdExchange文檔中下載。

漏洞

谷歌後來宣佈建議從發佈商網站域名中刪除其廣告套件中的幾個有問題的Busers，筆者決定對還存在的一些Busers以及DoubleClick未使用的更受歡迎的Busers做一下審查。結果發現大多數Busers中都存在基於DOM的XSS跨站腳本攻擊漏洞，本文中將會介紹一些特例來說明。

Adform IFrame Manager（1.7.48）

我們使用早版本的Adform為例來做介紹。相關源碼如下：

如上所示，該buster只接受一個源URL，這個URL將作為外部JavaScript源寫入DOM。上面的相關正則表達式測試，用來對將傳遞的腳本源URL做限制只允許特定域為白名單。

我們對該正則表達式分析，首先可以看到URL以"https：//"開頭並以"{任意字符}.adform.com"結尾。除了斜槓"/"之外，這部分允許插入任何其他字符。對於個過濾，我們可以輕易構建特定的URL來繞過白名單。例如，要嵌入攻擊腳本，可以使用：

改URL 的GET參數和故意錯誤URL個格式錯誤（反斜槓而不是轉發）正好滿足了正則表達式規則。在下面的示例中我們會看到，大多數已識別的漏洞都遵循類似的弱白名單過濾模式。

Eyeblaster

addineye iFrame Buster現在可以在很多大網站上看到。其完整的源代碼有點冗長，我們節選我們專注地該漏洞部分_prepareVerificationJsonObj，其中JSON對象是由攻擊者控制的document.location.search字符串發起的：

由於最終JSON對象會傳遞給_sendAddInEyeVerificationToServer，我們倒推回去，可以看到它是從strAie查詢字符串參數中找到的雙冒號分隔字符串派生的。所以，我們可以在_prepareVerificationJsonObj中設置任意域和路徑，而跳過白名單檢查。一些完整的PoC URL示例如下所示：

Adtech

Adtech還存在一個白名單弱過濾的例子，源碼如下：

在上面的實現中，代碼首先會從傳遞的腳本URL中提取域，並確定它是否存在於allowed_domains白名單中（數組）。正則表達式中的問題乍看可能還不好看出來，但請注意它在冒號之前，對域做解析的部分，實際上可以匹配任何字串。為了繞過這一點，攻擊者只需要滿足白名單，同時使瀏覽器實際請求來自其他來源的文件。

為了達到這樣目的，我們通過在URL中提供嵌入式基本身份驗證認證來完成，構造的PoC示例如下：

注意，由於Chrome 59版本59已經停止了嵌入式認證支持，因此該PoC無法在Chrome中運行，儘管它仍適用於大多數其他瀏覽器，包括Firefox。

Jivox

iFrame Buster XXS漏洞的最後一個示例，他有一個和上述不同類型的漏洞導致XSS。其源碼如下圖所示：

一般而言，我們最想做做的是要控制的重要變量iBusterResource URL，它最終用於填充腳本標記的src屬性。而該參數在父頁面已經在寫入DOM的字符串了，所以我們只需要在附加此字符串之前偷偷的將其改為我們的URL，同時使其餘部分與實際請求無關。

關鍵是，在"."字符上也有拆分，所以傳遞的URL的第一個子域是代碼作者希望接收的。

另外，注意到在document.write之前調用了一個unescape。所以著我們可以使用雙重編碼來滿足這兩個條件來繞過限制：

在URL解碼後，會生成iBusterResourceURL值：

最後，在unescape之後：

最後的散列使剩餘的硬編碼字符越過了URL的限制。

最佳實踐

如果使用正則表達式子來過濾+白名單的限制邏輯，則可能存問題和bug。如果需要在JavaScript中做域解析，實現白名單，最好最安全的解決方案是使用DOM 接口，比如：

閱讀更多 蟲蟲安全 的文章

關鍵字: 解析 編程語言 JavaScript