OAuth Security Issue

昨日はこの話題に振り回された気がします。
別に、うちはまだOAuthやってないから影響うんぬんはないんですが。

■ 何ができる？

Request Tokenの認可処理のところでsession fixation attackが可能ときました。

OAuthの認可フローおさらい

ConsumerがSPに未認可のRequest Tokenを要求し、認可を得るためにUserをSPにリダイレクトさせる
UserはSPにサインインし、Consumerに対してリソースアクセスの許可を与える
UserはSPにリダイレクトされ、Consumerはリソースアクセスの処理を行う

1,2,3のステップの中で、Request TokenはAuthorization URIとcallback URIの両方に含まれます。
どちらのURIも署名はされていません。
問題は、これらの3ステップが同じUserによって行われることを確かめる方法がないことです。
ステップ1,3はConsumer上の処理なのでCookieやSession管理ツールでUserを確認できますが、2の処理はSP側の処理です。

攻撃方法としては、次のようになります。

攻撃者はOAuthの認可処理を開始し、Request Tokenを含むAuthrization URIを保存しておく。このときcallback URIを変えておくかも(後述)
攻撃者はSocial Engineeringにより犠牲者にそのリンクをクリックさせる
犠牲者がRequest Tokenに認可を与えたタイミングで、攻撃者はなんとかして犠牲者が認可したRequest TokenとConsumer上の自分のSessionをつなぐ
Consumerは犠牲者が認可したRequest Tokenを攻撃者のものとして扱い、犠牲者のデータが攻撃者にとられてしまう

上記の3ステップで例えると、ステップ2を犠牲者に行わせることになります。

また、callback URIについても説明されています。callback URIの制限には次のようなパターンが考えられます。

どんなURIでも許可
登録されたドメイン上のURIならば許可
パラメータのない静的URI
callback URIのオプションを利用せず、手動でUserがConsumerに戻る

1ならば、犠牲者がRequest Tokenに認可したことを気付かせるためのURIを用意し、そのURIをcallbackに指定することで攻撃者のやりたい放題です。
2,3ならば、犠牲者、攻撃者のどちらが先にRequest TokenからAccess Tokenを取得するかにかかってきます。
攻撃者は犠牲者のアクセス許可を待ちながらブルートフォースアタックをするでしょう。
Consumer側はそのようなアタックが来ることを予想して対応する必要もあります。
また、2の場合は登録したドメイン内のリダイレクタを利用されることも考えられます。
4の場合、Userは手動作業によるオペミスを起こす可能性があるため、SPは何度もトライできるような実装にするかもしれません。
また、Consumerの処理がRequest TokenとAccess Tokenの交換のみになると、SP側で交換エラーになった時点でトランザクションを削除しなければアタックの脅威が増加するでしょう。

これだけではありません。
Consumerの作り次第では、この脆弱性に弱くなってしまいます。
もしConsumerがAccess Tokenを紐づけるときにフローを始めたUserと紐づける実装になっていたら、
Request Tokenは攻撃者に与えられたものなので、犠牲者のAccess Tokenと攻撃者が紐づいてしまいます。

■ OAuth SPはどうした？

Twitter,Yahoo!などのOAuth SPはRequest Tokenに認可を与えるAuthorization URIを無効化しました。
また、既に発行済のAccess Tokenには影響はありません。

■ どうやって修正？

こんな方法を考えているようです。