Facebook: HTTPSサイトを狙うBREACH攻撃対策

https://m.facebook.com/notes/protect-the-graph/preventing-a-breach-attack/1455331811373632

1 comment | 1 point | by WazanovaNews 2年以上前 edited


Jshiike 2年以上前 edited | ▲upvoteする | link

BREACHについてはまったく知識がなかったので、Facebookのセキュリティチームのこのブログは興味深かったです。

まず前提としてFacebookは、よく知られているクロスサイトリクエストフォージェリ(CSRF)攻撃への対策として、FacebookユーザにCSRFトークンを発行。トークンは攻撃者が簡単に発見できないもので、トークンを提示しないかぎりは他人になりかわってFacebookにwebリクエストをすることができない。この仕組みで、攻撃者に利用されて意図しない攻撃に参加させられるケースを防いでいます。

しかし、webページの内容が圧縮される際に暗号化されているとしてもトークンを見つけられてしまう可能性あり。

圧縮技術は、テキストの繰り返し表現を一度しか送信しなくて済むので、通信スピードをあげるのに役立つ。例えば、"Beetlejuice" という言葉が三回繰り返して使われている場合、二回目と三回目は、一回目を参照している短いショートカットに置き換える。同様に、また残念なことに、CSRFトークンの文字とかぶる文字がwebページにある場合も、それらの文字は圧縮の対象になってしまう。webページを暗号化したとしてもこのサイズの差分は残ってしまうので、圧縮されたwebページのサイズを把握できる攻撃者は、その差分をwebページの情報を読み取るのに利用する。賢い攻撃者は、工夫をこらしたwebリクエストを数百回繰り返すことで、サイズ情報のみからトークンを読み取ることができる可能性がある。

実際に被害が起きるケースは、「攻撃者が利用されるユーザの暗号化されたトラフィックを盗み聞きして、悪意のあるサイトに誘導し、CSRFトークンとユーザのインプットを含む圧縮されたwebページの情報を見つけて読み取る。」という条件をクリアできた場合となります。

このBREACH攻撃への対策として、

Facebookは、CSRFトークン内にセキュリティのレイヤを追加することでユーザを守っている。BREACH攻撃が編み出される前は、トークンは日替わりでローテーション。CSRFトークンは、アカウントIDと日付を組み込んだSHA-2ハッシュを短めにしたものを含んでいた。同じ日にFacebookに三回アクセスするユーザは、各セッションで同じトークンを使っていた。現在は、リクエストの度に新たにトークンが発行されるかたちに変更。... その新しいトークンの生成には、ランダムな24ビットのソルトが利用されている。ソルトはトークンに付加される最後の4文字で、ハッシュにも使われるようになっている。これによりトークンに同じ表現が含まれることを防いでいる。新しいトークンが発行されても、従前のトークンは数日間は有効で、複数のトークンが受け入れられるかたちになっている。... 現在では、攻撃者が毎秒1万回のリクエストを送っても、同じトークンに二度出くわすことは難しい。

(追記: 原文の "which eliminates all repetition anywhere in the token" が意味するところの理解がちょっと自信ないです。「ハッシュ値が毎回ユニークになるので、圧縮データの差分からトークンを類推するのが相当難しくなる。」という解釈でよいか?)

これでかなりリスクは軽減できますが、完全な防御策はない中で、Facebookがこの対策を選択した理由は、

ペイロードにランダムな情報を付加するのは、防御するというよりも、被害を遅らせることにしかならない。圧縮を利用しないようにすると、Facebookのサイトのスピード、特にモバイルが大きく下がる。リファラーをチェックして、信頼できるリファラーの時だけ圧縮をするという対策を取るサイトもいると思うが、Facebookの機能は大量のサードパーティのサイトで組み込まれているので、これもまたブラウジングするスピードにネガティブな影響を与えてしまう。

#facebook #セキュリティ

Back