Home » Computer » Software » Browser » Archive by category "Safari"

WebKit 對 HSTS Super Cookie 提出的改法

Twitter 上看到 WebKitHSTS 所產生的 Super Cookie 提出的改善方案:

拿原文的例子來說明,先指定一個隨機數給 user,像是 8396804 (二進位是 100000000010000000000100),所以就存取下面的網址:

https://bit02.example.com
https://bit13.example.com
https://bit23.example.com

在存取這些 HTTPS 網址時都會指定 HSTS,所以之後連到這三個網址的 HTTP request 就不會觸發到 HTTP 版本,會因為 HSTS 被轉到 HTTPS 版本。於是就可以用 32 個 HTTP request 測試 32bits 而判斷出身份。(當然你可以用更多)

WebKit 提出的改善方案大概有幾種,主要是就觀察到的現象來限制。

第一種解法「Mitigation 1: Limit HSTS State to the Hostname, or the Top Level Domain + 1」是因為會看到這樣的設計:

https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.example.com
…etc...
https://bit00.example.com
https://bit01.example.com
https://bit02.example.com
...etc...
https://bit64.example.com

所以提出的方案是只有目前網站的 domain 以及 top domain + 1 (像是 example.com) 可以被設定 HSTS:

Telemetry showed that attackers would set HSTS across a wide range of sub-domains at once. Because using HSTS in this way does not benefit legitimate use cases, but does facilitate tracking, we revised our network stack to only permit HSTS state to be set for the loaded hostname (e.g., “https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com”), or the Top Level Domain + 1 (TLD+1) (e.g., “https://example.com”).

但其實廣告主只需要註冊 32 domains (或是 64) 就可以避開這個問題。

第二種是「Mitigation 2: Ignore HSTS State for Subresource Requests to Blocked Domains」,如果在 HTTPS 頁面上,某個 domain 的 cookie 已經因為某些原因被阻擋 (像是手動設定),那麼就忽略掉 HSTS 的設計:

We modified WebKit so that when an insecure third-party subresource load from a domain for which we block cookies (such as an invisible tracking pixel) had been upgraded to an authenticated connection because of dynamic HSTS, we ignore the HSTS upgrade request and just use the original URL. This causes HSTS super cookies to become a bit string consisting only of zeroes.

後面這點在現在因為 SEO 設計而使得各大網站都往 HTTPS 方向走,應該會有些幫助吧...

nginx 的 HTTP/2 要支援 Server Push 了

Twitter 上看到 nginx 的 HTTP/2 也要支援 server push 的消息了:

看起來是只要送出對應的 HTTP Header,後續 nginx 就會幫你處理...

這功能總算是要進 nginx 了... 像是透過 cookie 判斷使用者是第一次瀏覽,就透過 server push 預先把 css/js 丟出去,加速頁面呈現。

所有主流瀏覽器的最新版都支援 WebAssembly 了

Mozilla 的「WebAssembly support now shipping in all major browsers」提到了最近幾個禮拜,新版的 SafariEdge 都相繼支援 WebAssembly 了:

In the past weeks, both Apple and Microsoft have shipped new versions of Safari and Edge, respectively, that include support for WebAssembly.

由於 ChromeFirefox 都已經支援了,這宣告 WebAssembly 的障礙都已經排除了,接下來只是時間的問題... 對於需要效能的應用程式來說多了一個方式加速。

利用手機的 sensor 取得 PIN 碼

把 side-channel information 配合上統計方法就可以達到 74% 的正確率:「Phone Hack Uses Sensors To Steal PINs」。

透過 browser 的 javascript 就可以拉出這些資料,然後利用這些資料去猜你的手機 PIN 碼:

Researchers from U.K.-based Newcastle University created a JavaScript app called PINlogger.js that has the ability to access data generated by the phone’s sensors, including GPS, camera, microphone, accelerometer, magnetometer, proximity, gyroscope, pedometer and NFC protocols.

而且當可以多抓到更多資訊時 (像是第二次輸入) 準確度就更高了:

Using a sample set of 50 PINs, researchers found that their script was able to correctly guess a user’s PIN 74 percent of the time on the first try, which increases to 86 and 94 percent success rates on the second and third attempts.

有些瀏覽器有做一些修正,讓 side-channel information 變少,於是難度變高:

As for Firefox, starting from version 46 (released in April 2016), the browser restricts JavaScript access to motion and orientation sensors. Apple’s Security Updates for iOS 9.3 (released in March 2016), suspended the availability of motion and orientation data when the web view is hidden, according to researchers.

Google 則是沒修:

As for Google, it’s unclear what measures have been taken. “Our concern is confirmed by members in the Google Chromium team, who also believe that the issue remains unresolved,” the report stated. Google did not reply to a request to comment for this report.

這攻擊方式頗不賴... @_@

iOS 阻擋 WoSign 憑證

mozilla.dev.security.policy 上看到有人行動了:「Apple's response to the WoSign incidents」。這使得 Apple 成為 WoSign 事件中第一個行動的單位。

Apple 這次先把 WoSign 放入 iOS 憑證清單的黑名單公告在這邊:「Blocking Trust for WoSign CA Free SSL Certificate G2」。

WoSign 在 iOS 產品線中是靠 StartComComodo 的交叉簽章,所以如果 Apple 只想擋 WoSign 憑證的話,必須以阻擋 Intermediate CA 的方式避開:

Although no WoSign root is in the list of Apple trusted roots, this intermediate CA used cross-signed certificate relationships with StartCom and Comodo to establish trust on Apple products.

不過為了降低對 user 的影響,這次的阻擋會有例外。當 CT log server 在 2016-09-19 前收到的 SSL certificate 還是會信任 (要注意的重點是,這邊的日期不是簽發,是送到 CT log server 上):

To avoid disruption to existing WoSign certificate holders and to allow their transition to trusted roots, Apple products will trust individual existing certificates issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19.

接下來會開始更深入的調查 WoSign 與 StartCom:

As the investigation progresses, we will take further action on WoSign/StartCom trust anchors in Apple products as needed to protect users.

另外本來的棚子裡,Qihoo 360 與 StartCom 正式提出要求在 2016/10/04 與 Mozilla 的人面對面討論 (在英國):「WoSign and StartCom: next steps」:

Following the publication of the recent investigative report, representatives of Qihoo 360 and StartCom have requested a face-to-face meeting with Mozilla. We have accepted, and that meeting will take place next Tuesday in London.

繼續來看進度... 下個禮拜應該會有更多的資料出來。

Webkit 推出 B3 JIT Compiler (Bare Bones Backend)

Webkit 推出了 B3 加快 optimization 的速度,取代原來 LLVM 的工作:「Introducing the B3 JIT Compiler」。

在文章後方 Performance Results 的部份可以看到最主要的差異在啟動時間:

另外也可以看到其他各種 performance benchmark 也幾乎都是小勝 LLVM。

接下來會有 ARM64 與其他平台的計畫:

B3 is not yet complete. We still need to finish porting B3 to ARM64. B3 passes all tests, but we haven’t finished optimizing performance on ARM. Once all platforms that used the FTL switch to B3, we plan to remove LLVM support from the FTL JIT.

在 iOS 9 裡安裝 Crystal 擋掉全版廣告

蘋果的 iOS 9 在今天放出來了,更新完以後可以用 Content Blocking 擋廣告,剛剛測過可以擋下全頁式的廣告。

這篇要介紹了的是「Crystal」這個目前限時免費的 app,你可以在「Crystal - Block Ads, Browse Faster.」這邊下載安裝。

iOS 9 的 Content Blocking 功能必須要應用程式支援,而目前只有 Safari 有支援,所以以下的測試是用 Safari 打開行動版的 Facebook (https://m.facebook.com/) 測試的,就拿這篇先來測試:(這張圖片是後來抓的,所以時間是 06:20)

直接打開會先出現全版廣告 (第一張圖),關掉後還會有大量的廣告 (第二張圖):

接著我們打開 Crystal,可以看到什麼都沒得設,因為這套軟體已經做完了:(這張圖片是剛裝完就裝的,所以是 06:00)

接著到「設定」裡面打開 Safari 的阻擋功能:

改完後就會是乾淨而且沒有廣告的版本了:

Archives