揭秘第三方跟蹤器是如何利用Facebook登錄頁面跟蹤用戶的

到目前為止，我已經陸續發布了如何通過網路跟蹤器從網頁、瀏覽器密碼管理器和表單輸入中盜取信息的文章。

今天，我會繼續發布我最近新發現的如何利用第三方腳本進行的隱私數據收集。具體過程就是通過登錄Facebook以及其他類似的社交登錄API，從網站中找到個人標識符，對用戶進行跟蹤。具體來說，我發現了兩種類型的漏洞[1]：

1.有7個第三方網站訪問並濫用了Facebook用戶的數據；

2.有一個第三方使用自己的Facebook「應用程序」來跟蹤網路上的用戶；

漏洞1：第三方利用了Facebook官方授予其網站的訪問許可權

當用戶點擊「登錄Facebook」時，他們會被進行這樣的提示：你所訪問的網站有權訪問你Facebook的某些個人資料信息[2]。即使在Facebook最近鎖定該功能後，網站也可以在不觸發Facebook人工審核的情況下，請求用戶的電子郵件地址和公開個人資料，如姓名、年齡範圍、性別、地區和個人資料照片。一旦用戶允許第三方網站訪問這些信息，任何嵌入頁面的第三方Javascript（如上圖中的tracker.com）也可以檢索用戶的Facebook信息，就好像它們是第一方（ the first party）[3]（比如Facebook本身）一樣。

出於安全考慮，有時用戶會把登錄密碼設置的很複雜。所以Facebook登錄和其他社交登錄系統就會通過減少要記住的密碼數量來簡化用戶的帳戶創建過程。但是社交登錄也會帶來風險，比如，這段時間鬧得沸沸揚揚的劍橋分析公司，就被發現利用性格測試應用程序收集用戶數據，該應用程序使用的就是Facebook的登錄功能。除此之外，我還發現了其他的風險，比如，當用戶授予網站訪問其社交媒體資料時，他們不僅信任了該網站，而且還信任該網站上嵌入的第三方。

我目前總共發現了有7個腳本使用了第一方的Facebook訪問收集Facebook的用戶數據[4]。這些腳本目前已嵌入在排名前100萬個站點中的434個中。我會在附錄1中詳細介紹如何發現這些腳本的？這些腳本中的大多數會獲取用戶ID，以及電子郵件和用戶名等附加配置文件信息，目前我還無法確定第一方是否知道這種特定的數據訪問[5]。

通過Facebook API收集的用戶ID特定於某些網站（Facebook賦予許可權的），雖然這將限制跨站點跟蹤的可能性，但是這些應用程序範圍的用戶ID可用於檢索全局Facebook ID，用戶的個人資料照片和其他公共個人資料信息，這些信息可用於識別和跟蹤網站和設備上的用戶[6]。

上圖表明它們在濫用瀏覽器自動填寫來收集用戶的電子郵件地址，另外Opentag標籤管理器載入的腳本包含訪問Facebook API並將用戶ID發送至https://c.lytics.io/c/1299?fbstatus=[...]&fbuid=[...]&[...]形式的代碼片段。此片段似乎是lytics.github.io網站上的一個示例代碼片段的修改版本，原代碼片段不但可以捕捉Facebook事件，似乎還為第一方提供了收集Facebook用戶標識和登錄狀態的說明。

儘管我觀察到這些腳本可以用來查詢Facebook API並保存用戶的Facebook ID，但由於其代碼經過了混淆以及測量方法的限制，我們無法驗證這些代碼是否發送到其伺服器。

第三方腳本可以直接從Facebook API獲取數據，上面的代碼片段來自OpenTag腳本，它會將用戶的Facebook ID泄漏到Lytics，Lytics是一個個性化的營銷和客戶數據平台。為了講解的方便，我添加了注釋，並進行了簡化，原始腳本在這裡可用。該腳本會持續檢查Facebook API的存在(通過window.FB獲得)。一旦用戶登錄到Facebook，跟蹤的腳本就可以悄無聲息地查詢用戶的登錄狀態。對登錄狀態查詢的響應包含用戶的Facebook ID，然後腳本從響應中解析ID並將其發送回遠程伺服器。

雖然我還不能總結全這些追蹤者如何使用他們收集的信息，但可以檢查他們的廣告銷售材料，了解他們如何使用這些信息。OnAudience，Tealium AudienceStream，Lytics和ProPS都提供某種形式的客戶數據平台，它們都會收集數據並協助黑客將數據轉化為利潤。Forter為電子商務網站提供基於身份的欺詐預防，Augur提供跨設備跟蹤和消費者識別服務，目前我還無法確定擁有ntvk1.ru域名的公司。

漏洞2:通過Facebook登錄服務跟蹤網路用戶

一些第三方使用Facebook登錄功能在許多網站上對用戶進行身份驗證，比如Disqus，Disqus是一家第三方社會化評論系統,主要為網站主提供評論託管服務。然而，隱藏的第三方追蹤器也可以使用Facebook登錄，來匿名化用戶，從而進行有針對性的廣告推送。這是一種侵犯隱私的行為，因為它未經用戶同意。但前提是，這些隱藏的跟蹤器是怎麼發現用戶登錄Facebook的呢?我想這個跟蹤器直接嵌入在用戶直接訪問的第一方。這個猜測是我在Bandsintown所發現的，更糟糕的是，攻擊者這樣做是為了讓惡意網站嵌入Bandsintown的iframe來識別用戶。

Bandsintown為用戶提供的數據是非常全面的，許多歌手都在使用Bandsintown來管理演出日期和各種活動，該服務能夠自動幫助歌手在其Facebook主頁發布演出信息，不僅大大簡化了信息從歌手傳遞到歌迷的流程，而且能夠為演唱會的推廣時間提供建議。

而對於粉絲來說，要想追隨他們的偶像，用戶需要登錄Facebook，並讓Bandsintown Facebook應用程序訪問他們的個人資料、城市、喜好、電子郵件地址和音樂活動。此時，Bandsintown可以訪問必要的身份驗證令牌來訪問Facebook帳戶信息。

另外Bandsintown提供了一種名為「Amplified」的廣告服務，該服務出現在許多頂級音樂相關網站上，包括lyrics.com，songlyrics.com和lyricsmania.com。當Bandsintown用戶瀏覽嵌入Bandsintown的「Amplified」的廣告服務時，廣告腳本嵌入一個不可見的iframe，該iframe使用先前建立的認證令牌連接到Bandsintown的Facebook應用程序，並獲取用戶的Facebook ID。然後，iframe將用戶標識傳遞迴嵌入腳本。

我們發現由Bandsintown注入的iframe會將用戶的信息不加區分地傳遞給嵌入腳本。因此，任何惡意網站都可能使用他們的iframe來識別訪問者。目前，我已經向Bandsintown通報了此漏洞，並確認該漏洞現在已經修復。

總結

Facebook數據對第三方的意外曝光，並不是由於Facebook的登錄功能出現了問題。相反，這是由於在如今的網路中，第一方和第三方腳本之間缺乏安全界限。儘管如此，Facebook和其他社交登錄提供商還是可以採取一些措施來防止，比如對API的使用進行嚴格審核，審核它們訪問社交登錄數據的方式。Facebook還可以通過應用程序範圍的用戶id來禁用配置文件圖片和全局Facebook id。其實，Facebook在四年前就宣布匿名登錄了。

在開頭提到的那幾篇文章中，我曾列出了三個站點(fiverr.com, bhphotovideo.com和mongodb.com)，它們嵌入了與上面給出的URL模式匹配的腳本。即使這些腳本來自相同或類似的url，第三方腳本在載入不同站點時可能包含不同的內容。經過分析，嵌入fiverr.com和bhphotovideo.com的Forter腳本不包括訪問Facebook數據的功能。在mongodb.com上，我們只看到了一個Augur腳本的存在。我已經發布了一個經過更新的網站列表，這裡面的API已經確認了訪問Facebook數據的功能。

另外，我曾在以前的文章中列出了Lytics腳本（https://c.lytics.io/static/io.min.js）來作為Facebook API訪問的原因。儘管此腳本用於將Facebook用戶ID發送給Lytics（c.lytics.io），但訪問Facebook API的代碼是在OpenTag腳本中提供的，如上所述。負責訪問Facebook用戶數據的OpenTag腳本中的代碼片段可能由第一方配置，因此我認為第一方可能不知道數據被訪問這回事。

附錄1

[1]我在文章中使用了術語「漏洞」來指當今網路中由於不安全的設計實踐而產生的問題，而不是平常所理解的計算機安全方面的漏洞。

[2]在這篇文章中，雖然我是以Facebook登錄為例的，但我描述的漏洞可能存在於大多數社交公司和移動設備上。事實上，比如，Google Plus API和俄羅斯社交媒體網站VK也可以獲取用戶標識符的腳本。

[3]當用戶在使用Facebook的Javascript SDK的網站上完成Facebook登錄過程時，SDK會在頁面中存儲身份驗證令牌。當用戶導航到新頁面時，SDK將使用瀏覽器的Facebook cookie自動重新建立認證令牌，所有對SDK的第三方查詢都會自動使用此令牌。

[4]為了更好地理解第三方與第一方的集成程度，我根據他們在登錄初始化階段向Facebook提供的第一方應用程序ID（或AppId）的使用對腳本進行了分類，以確定該網站。如果在第三方庫中包含網站的應用程序ID和初始化代碼表明集成更緊密，第一方可能需要配置第三方腳本以表示他們訪問Facebook SDK。雖然應用程序ID並不是什麼秘密，但我認為缺乏應用程序ID則意味著鬆散的集成，因為這樣第一方可能不知道訪問。事實上，上文中的所有腳本在嵌入簡單的測試頁面時都採用相同的操作，先前沒有任何業務關係。

[5]以下跡象可能表明第一方對Facebook數據了訪問：

1）第三方主動發起Facebook登錄過程而不是被動地等待登錄發生;

2）第三方包括它所嵌入的網站的唯一App ID，上面列出的七個腳本既不啟動登錄過程，也不包含網站的應用程序ID。

不過，很難確定第一方和第三方之間的確切關係。

[6]通過查詢Facebook的Graph API或者檢索用戶的個人資料照片（甚至不需要驗證），就可以將應用程序範圍的ID解析為真實的用戶個人資料信息。當安全研究人員將這個漏洞反饋給Facebook時，Facebook回復如下：

「這是我們在開發產品時，有意設置的行為。雖然我們並不認為這是一個安全漏洞，但我們確實要採取控制措施來監控和緩解濫用行為。」

據報道，擁有類似控制功能的Facebook界面曾獲取了20億Facebook用戶的公開個人資料數據。請注意，儘管研究人員發現的終端不再公開運行，但以下終端仍然會重定向到用戶的個人資料頁面： https://www.facebook.com/[app_scoped_ID]。

附錄2：研究分析的方法

為了研究社交登錄API的濫用情況，我擴展了OpenWPM以模擬用戶已經在所有網站上進行了身份驗證並給予Facebook登錄SDK的完全許可權。我添加了一些工具(比如「windows . fb」)來監視Facebook SDK界面的使用，另外，由於我沒有以其他方式將用戶的身份注入頁面，因此任何被泄漏的個人數據都必須從我的spoofed API中查詢。

我在2017年6月從Alexa 100萬個網站上抓取了500萬個網站，並採用以下抽樣策略：訪問所有前15000個網站，我隨機抽取了Alexa的排名範圍在15000到100000中的15000個網站，以及Alexa的排名範圍在100000到1000000中的20000個網站。這個抽樣組合使我們能夠觀察到攻擊者對高流量和低流量網站的攻擊區別。在這5萬個網站中，我們訪問了6個頁面，即首頁和從首頁的內部鏈接隨機抽取的一組其他5個頁面。

為了模仿用戶登錄，我們創建了自己的`window.FB`對象並複製了Facebook SDK 2.8版的介面。被欺騙的API都具有以下屬性：

1.對於通常返回個人信息的方法調用，我會欺騙返回值，就好像用戶已經登錄並調用了必要的回調函數參數。

其中包括用於事件`auth.login` ，`auth.authResponseChange`， `auth.statusChange`和`FB.getAuthResponse()`的 `FB.api()`, `FB.init(), `FB.getLoginStatus()`,和FB.Event.subscribe()` 。

另外對於Graph API (" FB.api ")，它支持真正的Facebook SDK支持的大部分配置文件數據欄位。這樣我就能解析請求的欄位並以真實Graph API返回的相同格式，返回一個數據對象。

2.對於不返回個人信息的方法調用，我只需調用一個無操作函數並忽略任何回調參數。如果網站調用了一個我無法完全複製的方法，這有助於最大限度地減少用戶的跟蹤。

3.一旦文檔載入完成，我就會觸發`window.fbAsyncInit`。這個函數通常由Facebook SDK調用。

因此，無論是否存在真正的Facebook SDK，欺騙性的`window.FB`對象都會被注入到每個頁面載入的每一個框架中。然後，使用OpenWPM的Javascript通話監控來監控對API的訪問。監控對象包括所有的HTTP請求和響應數據，就連HTTP POST有效載荷都會被檢查，以檢測任何偽造的配置文件數據（包括被散列或編碼的數據）是否發生泄漏。

對於`window.FB`和HTTP數據的調用，我都會在執行時存儲Javascript堆棧跟蹤。通過使用這個堆棧跟蹤就可以了解哪些API腳本被訪問以及他們何時發送數據。對於某些腳本，我只負責捕獲API訪問許可權，而不負責泄漏。因此在這些情況下，我通過手動調試腳本以確定數據是僅在本地使用還是在傳輸之前就被混淆，不過這方面我目前還做的不夠好。

附錄3：第三方如何偽裝成第一方訪問Facebook API

我還發現了許多與Facebook API交互的第三方腳本，這些腳本似乎會第一方運行[4]。這些公司提供一系列服務，例如集合多個社交登錄選項，監控社交媒體參與度以並聚合客戶數據。比如BlueConic提供了一個Facebook配置文件傳輸服務，該服務將用戶的Facebook個人信息複製到BlueConic的數據平台上。其他第三方服務包括:Zummy、Social Miner、Limespot (personalizer.io)、Kissmetrics、Gigya和Webtrends。不過，Limespot已經通知我，他們在2017年11月就停用了相關功能。

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