Facebookが考える署名付きCookieを用いたブラウザアクセスとは

今日は、この前の続きを少し。
Facebookのここ最近のアナウンスにより、OAuth 2.0 + HTTPS化が進めらるような話が聞こえてきましたがそれは特に心躍るような話ではありません。
個人的に気になるのはこの部分です。

  • A secure signed cookie specification. While we're moving Facebook to use HTTPS, the vast majority of the Internet still sets session cookies in the clear. The MAC Access Authentication specification is a secure session cookie protocol designed to provide cryptographic protection against stealing session cookies transmitted without HTTPS. We’re working with Yahoo!, Google and Mozilla on this specification in order to give all websites a way to ensure that session information has not been altered or tampered with.
https://developers.facebook.com/blog/

これは、単純にOAuth 2.0でGraph APIへのアクセスにMAC Access Tokenを使うという話ではありません。

  • FacebookはHTTPS化を進めるが、それ以外のかなりのサイトはセッションクッキーをHTTP環境でセットする
  • MAC Access AuthNの仕様は非HTTPSで転送されるセッションクッキーが盗まれるのを防ぐための暗号保護を提供する、安全なセッションクッキープロトコルである

セッションクッキーのやりとりを安全にすると言ってるので、普段のブラウザアクセスの話なのではないかと。

中の人ではないので間違っているかもしれませんが、Facebookが考えている安全なブラウザアクセスの姿を想像してみます。

1. Server : セッションクッキーの発行

ログイン状態の保持、管理のためにいろんなサイトがセッションクッキーを利用していますが、次のようなSet-Cookieヘッダで指定されます。

Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com;

他にもパラメータはありますが(expires,secureなど)、ここでは省略します。
MAC Access AuthNを利用する場合、ログイン処理の後に次のようなMAC-Key, MAC-Algorithmという属性が追加されたヘッダが出力されます。

Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com;
MAC-Key=8yfrufh348h; MAC-Algorithm=hmac-sha-1

最近のOAuth 2.0の仕様に詳しい方には、このような説明がわかりやすいでしょうか？

  • クッキー名SIDの値 "31d..." : OAuthでいうアクセストークン
  • MAC-Key属性の値 "8yf..." : MAC計算のための共有Secret
  • MAC-Algorithm属性の値 "" : アルゴリズム

ここで盗まれたら最初から何の意味もないですが、ログイン処理はHTTPSで他はHTTPっていうサービスは普通にたくさんありますよね。そういうところを想定しているのでしょう。

2. User-Agent : クッキー処理

次は、クッキーを受け取ったブラウザの処理です。
追加された属性を保存する必要があります。

ここはブラウザやHTTP Clientが対応する必要がありますね。

3. User-Agent : MAC付きAuthZ Headerの作成と送信

次は、このいわゆるログイン状態でページにアクセスするときのリクエスト作成処理です。
ここでは、"Authorization" Headerを利用します。
その値は、前回のエントリにあるとおりです。
MAC Access Authenticationの仕様をキャッチアップ

ブラウザはMethodやパラメータの状態を知っているわけなので、MAC計算も可能です。
MAC-*属性を持つアクセスにおいて全てこの計算が必要になるとなりますが、今もHTTPSの処理なんかやっているわけなので問題なさそうですよね。

POST /request HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: MAC id="jd93dh9dh39D",
nonce="273156:di3hvdf8",
bodyhash="k9kbtCIy0CkI3/FEfpS/oIDjk6k=",
mac="W7bdMZbv9UWOTadASIQHagZyirA="

hello=world%21

このとき、Cookieは送らなくてもいいかもとか仕様に書いてあります。
まぁ、MAC-Keyが流出するのが一番良くないことになります。

4. Server : MAC付きAuthZ Headerの検証

Server側は、検証を行う必要がありますね。
この処理については、想像するとなかなか大変かなと思ったりします。

  • 1. MAC idとMAC Key(+MAC Algorithm)の組み合わせの検証
  • 2. nonce(タイムスタンプ＋文字列)の検証
  • 3. MAC計算

大規模なWebサービスを展開するY!のようなところがやろうと思うと、何か工夫が必要がもしれませんね。
Proxyかまして全て処理するか、まぁ他にもいろいろ。

これで幸せになれるのか？

現在使われているHTTP Cookieのやりとりは、OAuthでいうbearer tokenです。
重要ないくつかのCookieが盗まれてしまったら、比較的簡単に第3者にログイン状態になり済まされてしまうでしょう。

今回のAuthZ Headerの値を利用すれば、MAC-Keyが漏えいしなければ有効なAuthZ Headerを作ることができないわけなので、少し安全になるかもしれません。
Serverは大変ですがnonceの管理をしっかりしていれば、同じリクエストを繰り返してくるような攻撃も判断して対応できそうです。

今後どのような展開を見せるかわかりませんが、引き続きウォッチしていきましょう。
ではまた！