跨瀏覽器追蹤的方式

看到「Exploiting custom protocol handlers for cross-browser tracking in Tor, Safari, Chrome and Firefox」這個方式,跨瀏覽器收集 fingerprint 追蹤。

這次用的方式是透過 handler 追:

The scheme flooding vulnerability allows an attacker to determine which applications you have installed. In order to generate a 32-bit cross-browser device identifier, a website can test a list of 32 popular applications and check if each is installed or not. On average, the identification process takes a few seconds and works across desktop Windows, Mac and Linux operating systems.

最近大家比較常使用到的應該就是 Zoom 從網頁把應用程式帶起來的方式:

而要怎麼偵測的部份,用到了不同瀏覽器的 side channel。

Chromium 系列的部份對應的 ticket 在「Issue 1096610: External Protocol handler anti-flood protection is ineffective and flaky」這邊有被提出來。主要用到的方法是,在遇到有 handler 時,連打兩次時會被擋下:

被擋下後再打都會失敗,所以需要一個方式重設 flag,而內建的 Chrome PDF Viewer 剛好可以重設 flag:

The built-in Chrome PDF Viewer is an extension, so every time your browser opens a PDF file it resets the scheme flood protection flag. Opening a PDF file before opening a custom URL makes the exploit functional.

Firefox 的 side channel 則是可以透過 same-origin policy 測試當作 side channel,對應的 ticket 在「Scheme flooding technique for reliable cross-browser fingerprinting」這邊:

Every time you navigate to an unknown URL scheme, Firefox will show you an internal page with an error. This internal page has a different origin than any other website, so it is impossible to access it because of the Same-origin policy limitation. On the other hand, a known custom URL scheme will be opened as about:blank, whose origin will be accessible from the current website.

Safari 上的問題與 Firefox 一樣,不過沒登入看不到 ticket (也懶的註冊了):

You are not authorized to access bug #225769. To see this bug, you must first log in to an account with the appropriate permissions.

另外,雖然 Tor Browser 底層是 Firefox,但因為有改變預設值,所以攻擊者也得換方法:

Tor Browser is based on the Firefox source code, so the Same-origin policy trick was used here as well. But because Tor Browser does not show pop-ups, we used the same-origin policy trick with iframe elements instead.

這個方法還蠻暴力的...

用 uBlock Origin 過濾 URL 裡面的 tracking parameter

在「ClearURLs – automatically remove tracking elements from URLs (github.com/clearurls)」這邊的討論裡面看到 gorhill (uBlock Origin 的作者) 的回文,裡面提到了 uBlock Origin 目前也有支援 removeparam 了,而且有對應的 filter list 在維護這個表格:

不過他也有提到 CleanURLs 可以清更多東西:

Addendum: to be clear, this is not a replacement for ClearURLs. ClearURLs has more capabilities then just removing query parameters from the URLs of outgoing network requests.

但這樣起來也不錯了 (尤其是對於只裝 uBlock Origin 的情況下),可以訂起來...

GitHub 宣佈在 github.io 上抵制 FLoC

GitHub 的公告簡單明瞭,也不用你操作,直接在 github.io 上抵制 FLoC:「GitHub Pages: Permissions-Policy: interest-cohort=() Header added to all pages sites」,在「[Feature request] Set HTTP header to opt out of FLoC in GitHub Pages」這邊有些討論,另外在 Hacker News 上的討論也可以看一下:「GitHub blocks FLoC across all of GitHub Pages (github.blog)」。

不過不確定為什麼 custom domain 的就不加上去,可能微軟內部的法務團隊討論出來的結果?

All GitHub Pages sites served from the github.io domain will now have a Permissions-Policy: interest-cohort=() header set.

Pages sites using a custom domain will not be impacted.

WordPress 對 FLoC 的對抗計畫

Google 打算在 Google Chrome 裡面強推的 FLoC 最近有很多消息,但因為沒看完 spec 就一直丟著了... 可以先參考 iThome 的「繼Brave瀏覽器之後,DuckDuckGo、Vivaldi也要封鎖Google FLoC廣告投放技術」,雖然裡面提的很淺。

目前檯面上除了廣告產業以外,所有看到的人與組織都反對 FLoC。

EFF 的「Google’s FLoC Is a Terrible Idea」,之後 DuckDuckGo 也發表了「Use the DuckDuckGo Extension to Block FLoC, Google’s New Tracking Method in Chrome」,再來是 Brave 的「Why Brave Disables FLoC」與 Vivaldi 的「No, Google! Vivaldi users will not get FLoC’ed.」。

最新的進展是 WordPress 決定把 FLoC 當作 security concern 來看,打算直接推出 security hotfix 更新,預設關閉 FLoC:「Proposal: Treat FLoC as a security concern」,在 Hacker News 上也有討論:「Proposal: Treat FLoC as a security concern (make.wordpress.org)」。

主要的原因是正常的 WordPress 版本會在今年七月才出,會跟不上 FLoC 的進度:

Currently, 5.8. is only scheduled for July 2021. FLoC will likely be rolling out this month.

我自己也因為 FLoC 而又再次跳到 Brave,還遇到 imgur Uploader 套件不見 (可以參考「What Happen to the imgur uploader extension?」),以及有些套件無法運作的問題...

Facebook 5.33 億筆個資外洩,以及 Mark Zuckerberg 的電話...

這兩天應該已經有很多其他媒體報導了 Facebook 5.33 億筆資料外洩的事情:「533 million Facebook users' phone numbers and personal data have been leaked online」。

據稱是用 2019 年的洞撈出來的,不過這份資料看起來也不是完整資料,舉個例子來說,台灣只有 73 萬筆左右,而且也少了很多地區,像是泰國就不在列表內...

另外一個比較特別的是,Mark Zuckerberg 的電話也在這次外洩資料裡面:「Mark Zuckerberg's phone number appeared among the leaked data of Facebook users, according to a researcher」,應該會換號碼了。

這包資料看起來會這陣子會很熱門...

Mapbox GL JS 的授權改變,以及 MapLibre GL 的誕生

看到「MapLibre GL is a free and open-source fork of mapbox-gl-JS (github.com/maplibre)」這篇,翻了一下資料發現年初時 Mapbox GL JS 的軟體授權從 v2.0.0 開始變成不是 open source license (本來是 BSD license),而社群也馬上 fork 最後一個 open source 版本並且投入開發,變成 MapLibre GL

MapTiler 在年初的時候有提到這件事情:「MapLibre: Mapbox GL open-source fork」。

The community reacted swiftly: forks of the latest open-source version were made almost immediately by multiple parties. In another positive development, the community came together the next day and agreed to make this a joint effort, rather than splitting energies. A video call was organized and the MapLibre coalition was formed. It includes people working for MapTiler, Elastic, StadiaMaps, Microsoft, Ceres Imaging, WhereGroup, Jawg, Stamen Design, etc.

MapLibre GL 目前與本來 v1.13.0 相容,可以直接抽換過去 (後來在二月的時候有出一個 v1.13.1,不過那是在 v2.0.0 改 license 之後的事情了):

  "dependencies": {
-    "mapbox-gl": "^1.13.0"
+    "maplibre-gl": ">=1.14.0"
  }

記錄一下,以後要在網站上用的話,得注意到 Mapbox GL JS 在沒有註冊的情況下不能使用,而且 SDK 會強制蒐集資料:

Mapbox gl-js version 2.0 or higher (“Mapbox Web SDK”) must be used according to the Mapbox Terms of Service. This license allows developers with a current active Mapbox account to use and modify the Mapbox Web SDK. Developers may modify the Mapbox Web SDK code so long as the modifications do not change or interfere with marked portions of the code related to billing, accounting, and anonymized data collection. The Mapbox Web SDK only sends anonymized usage data, which Mapbox uses for fixing bugs and errors, accounting, and generating aggregated anonymized statistics. This license terminates automatically if a user no longer has an active Mapbox account.

不過如果是抓 OpenStreetMap 資料的話,Leaflet 應該還是目前的首選...

讓 Tor 的 .onion 支援 HTTPS

看到 Tor 官方的「Get a TLS certificate for your onion site」這篇,查了一下發現先前漏掉一些資訊...

首先是 2020 年二月的時候 CA/Browser Forum 就已經在投票是否有開放 v3 .onion 的憑證:「[Servercert-wg] Voting Begins: Ballot SC27v3: Version 3 Onion Certificates」,而結果也順利通過:「Ballot SC27v3: Version 3 Onion Certificates - CAB Forum」。

而一直到今年才有消息,希臘的 Harica CA 在月初時正式支援 v3 .onion:「Harica CA now supports issuance of DV .onion certificates」,不過拿 SSL Lab 的工具翻了一下,發現不是所有的平台都有認 Harica CA:「SSL Report: www.harica.gr (155.207.1.46)」,裡面可以看到 Java 的 trust store 裡面沒有 Harica CA:

實際測了一下流程,Harica CA 的網站會等到認證完後收費,看起來可以透過信用卡,但我就沒走下去了:

想要看看的人可以看 Kushal Das 的 kushaldas.inkushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion 就可以了。

另外查了一下 Certificate Transparency,可以看到我自己的 onion server 先被簽出來了:「5g4ukauwohjqjpydwqnkfkxxtcxkgtusr5twji53stfdzbz54xrmckid.onion」。

Let's Encrypt 出來後再說吧,目前看起來「Support for FQDNs under .onion」這邊沒有什麼進度...

Firefox 87 推出 SmartBlock 阻擋 3rd-party tracking

Firefox 87 推出了 SmartBlock,試著阻擋各種追蹤器:「Firefox 87 introduces SmartBlock for Private Browsing」,不過這不是一般的預設值,而是只有 Strict 模式與無痕模式會用到。

對於追蹤的問題,最早的作法是直接擋掉 3rd-party tracking javascript 的載入,但有很多網站會因為對應的變數沒有初始化而造成 javascript error。

這次的 SmartBlock 其實就是在各家阻擋套件實做很久的方式,插入一小段客製化的 javascript 讓網站裡的 javascript 可以呼叫,但實際上不會送任何資料出去,像是 uBlock Origin 的「unbreak.txt」。

不過 Firefox 重複搞這麼多東西,要不要考慮直接把 uBlock Origin 內建進來啊...

Google Chrome 要推動預設使用 HTTPS 連線

Google Chrome 從 90 版要把 https:// 變成網址輸入時的預設值:「A safer default for navigation: HTTPS」。Hacker News 上的「Chrome’s address bar will use https:// by default (chromium.org)」也可以看一下。

也就是說,沒有輸入 schema 的網址,預設會用 https:// 方式連線,以往這點需要透過 HTTPS Everywhere 這種套件,然後開啟「Encrypt All Sites Eligible」這樣的參數,像是這樣:

這樣會再推一把...

Zoom 在分享螢幕時會有資料安全性問題

看到「Zoom Screen-Sharing Glitch ‘Briefly’ Leaks Sensitive Data」這篇,講 Zoom 在分享螢幕時的安全性問題,發現問題的德國資安團隊所寫的 security advisory 可以在「SYSS-2020-044.txt」這邊看到,對應的 CVE 號碼是 CVE-2021-28133

安全問題出在,分享者要分享某個應用程式的畫面,但有可能會先分享到其他畫面,再切回來:

However, “under certain conditions” if a Zoom presenter chooses to share one application window, the share-screen feature briefly transmits content of other application windows to meeting participants, according to German-based SySS security consultant Michael Strametz, who discovered the flaw, and researcher Matthias Deeg, in a Thursday disclosure advisory (which has been translated via Google).

而目前的版本還是有一樣的問題:

The current Zoom client version, 5.5.4 (13142.0301), for Windows is still vulnerable to the issue, Deeg told Threatpost.

這個問題是去年十二月就通報了,過了三個月沒有回應,所以團隊公開出來:

Disclosure Timeline:

2020-12-02: Vulnerability reported to manufacturer
2020-12-02: Manufacturer acknowledges receipt of security advisory
2020-12-02: Manufacturer asks for more information
2020-12-03: SySS provides more information concerning the security issue
2020-12-03: Manufacturer confirms reproducing the security issue in both the Windows and the Linux client and asks further questions
2020-12-04: SySS answers open questions
2020-12-04: Manufacturer responds and will look into the reported security issue
2021-01-21: SySS asks for status update
2021-02-01: SySS asks for status update
2021-03-18: Public release of security advisory

不知道什麼時候會修正