Tag: csrf

Facebook 在對抗 BREACH Attack 的方法

在「Facebook Takes Tougher Stand Against BREACH Attack」這篇提到 Facebook 在 2012 年對抗 BREACH attack 的方法：

在文章最後面有提到當時一般建議的 migrate 方式 (關閉 TLS 的壓縮) 不適用於 Facebook：

Turning off compression is not an option for large dynamic sites such as Facebook because it would hinder performance dramatically.

而且就算關掉 TLS 的 compression，也還是有疑慮：

Even if TLS-level compression is disabled, it is very common to use gzip at the HTTP level. Furthermore, it is very common that secrets (such as CSRF tokens) and user input are included in the same HTTP response, and therefore (very likely) in the same compression context,

節錄幾段 migrate 的重點：

Facebook disclosed how it’s mitigating BREACH attacks by changing the frequency in which it rotates CSRF tokens from daily to each time a Facebook session is started.

本來 CSRF token 變更的頻率是好幾天一次，把頻率拉高...

After a new token is issued, the previous tokens still remain valid for a couple days, resulting in multiple tokens being permissible simultaneously.

然後舊的 token 還是會保持一段時間有效。

因為現實因素而沒辦法在 TLS 層關閉，後面在 application level 的 workaround 相當費功... (而且要多花不少資源？)

新的 HTTPS 攻擊：BREACH Compression Attack

也是一個禮拜前的消息，在 Slashdot 上看到對 HTTPS 的新攻擊，目前沒有好解法，NSA 應該開心到爆炸：「BREACH Compression Attack Steals SSL Secrets」。

說明可以參考「Vulnerability Note VU#987798 BREACH vulnerability in compressed HTTPS」這篇。

假設你的 ISP 想要抓出你的 Facebook (HTTPS) session id 或是 CSRF token (只要是有能力在中間攔截封包並修改資料的團體都可以，這邊以 ISP 為例)，作法是針對 HTTP 頁面值入 script，讓你的瀏覽器對 https://www.facebook.com/ 發出大量 request，藉由觀察這些 HTTPS 的長度就有機會取得 session id (或 CSRF token)...

CERT 的 security advisory 上是寫：

With a token of length 32 and a character space of size 16 (e.g. hex), the attacker needs an average of approximately 1,000 request if no recovery mechanisms are needed. In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests. A browser like Google Chrome or Internet Explorer is able to issue this number of requests in under 30 seconds, including callbacks to the attacker command & control center.

四千次就搞定了... 太！歡！樂！了！