今更OAuth Security Advisory: 2009.1を翻訳したり考えたりしてみる

OAuth 1.0 のセキュリティホール
OAuth のリクエストトークン認証フロー
（OAuth Core 1.0 Section 6）
に対するセッション固定攻撃が発見されました。

影響
OAuth 認証フロー（3-legged OAuth）を用いる
OAuth Core 1.0 プロトコルの通常の規定に則った実装すべて。

詳細
攻撃者が（真っ当な）コンシューマのサイトを訪れるところから攻撃が始まります。
場合によっては、
攻撃者がそのサイトに自身のアカウントでログインしている必要もあるでしょう。
攻撃者は OAuth 認証プロセスを開始しますが、
認証を得ることが目的ではないため、
コンシューマからサービスプロバイダへのリダイレクトを回避し、
（リクエストトークンを含む）認証リクエスト URI を取得し保持します。
その後、保護されたリソースへのアクセス権を得るために、
取得した認証 URI を含むリンクをターゲットにクリックするよう仕向けます。

リンクをクリックすると、攻撃者が開始した、
（真っ当な）コンシューマが攻撃者に発行したリクエストトークンが
含まれるリクエストを、ターゲットが継続することになります。
そしてターゲットは、サービスプロバイダの正当なページにリダイレクトされ、
（真っ当な）コンシューマへのアクセス権を与えるかどうかを尋ねられます。
ターゲットが攻撃されていることに気づく余地はありません。

ターゲットがアクセス権を譲与したのち、
攻撃者は保持しているリクエストトークンを用いて認証フローを完了することが出来、
サービスとして提供される保護されたリソースへ自由にアクセス出来る状態になります。
もし攻撃者がその（真っ当な）コンシューマサイトのアカウントを持っていたとしたら、
その不正なアクセスは将来にわたって続くことになるでしょう。

コンシューマサイト側の XSRF 対策ではこの攻撃を防ぐことは出来ません。
http://oauth.net/advisories/2009-1/

要約

攻撃者 A
ターゲット B
コンシューマ C（mixi とか Facebook とか）
サービスプロバイダ D（Twitterとか）

A「C に D のリソースへのアクセス権をあげるよ」
C「だそうなのでサインするための契約書をくださいな」
D「あいよ、これ使ってね」
C「この契約書にサインして D に提出してね」
A「この契約書にサインして D に提出してね」
B「OK!」
D「確認しました。
　 では今後 B さんのリソースへのアクセスするときは
　 その契約書を見せてね、サインは不要ですので＾＾」
A「はい、これ」
D「OK! B さんのリソースへアクセスする権利を与えよう」

対策
A「C に D のリソースへのアクセス権をあげるよ」
C「だそうなのでサインするための契約書をくださいな」
D「あいよ、これ使ってね」
C「この契約書にサインして D に提出してね」
A「この契約書にサインして D に提出してね」
B「OK!」
D「確認しました。
　 では今後 B さんのリソースへのアクセスするときは
　 その契約書を見せてね、割印があるので」
A「はい、これ」
D「おやその契約書は B さんにサインしてもらったもののはずだが」
A「ぐぬぬ」