こんにちは, ritouです.
ツールバーがブラウザがアクセスしたURLをごっそり収集する場合,
「"セッションIDを埋め込んであるURL"を収集することでなりすましの可能性がある」ことはご存知でしょうか？
OAuth 2.0でもあれだなーと誰でも気づくことをさくっと残しておきましょう。
いいたいのはこれだけ
これを言いたいだけです.
Authorization Responseにはフラグメント部分(location.hash)にAccess Tokenがついています.
http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600
Tポイントツールバーではlocation.hashまで送られるようなので, Access Tokenも収集されることになります.
もともとWebサーバーにも送られなくてイイねっつってlocation.hashに載せたのに残念すぎますね.
収集した側が何をできるかというと
- もちろんAPIアクセスできるようになります
- 別の脆弱なClientにToken置換攻撃をしかけることも・・・
前に話題になってたときもモバイルアプリとか言ってたじゃん, Implicitってモバイルのためのものじゃないの？
って思われる方もいらっしゃるかもしれませんが, 思ったより流行らなかったTwitter @anywhereのようにJavaScriptでImplicit使わせたりしてるとPCのブラウザからアクセストークン持っていかれる可能性は十分ありますね.
あと, このURL収集機能がモバイルブラウザに載ったら・・・
Server側が考えなければならないことは, Implicit Grantで想定されるリスクに加え, 利用できるScopeの制限するなどを検討することでしょうか.
リアルタイムでURLが送信される状況で悪用する部分までしっかり作りこまれたらAccess Tokenの有効期限を短くしてもやられますね.
いちおうAuthorization Code Grantについても考えます.
Authorization Code Grantで同じことはできない
Implicitと比べるとそのままで危険というわけではありません.
Authorization ResponseでこんなURLが収集されます、
https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
このあと, OAuth 2.0のClientはcodeパラメータとして渡されたAuthorization Codeを含んだPOSTリクエストをServerのToken Endpointに送ります.
その部分はサーバサイドで行われる場合がほとんどであり, クライアントサイドで送られるとしてもAuthorization Codeがワンタイムになっていれば再現してAccess Tokenを取得することはできないでしょう.
よって, 収集した側が他人のAuthorization Codeを自らのブラウザにペーストして他人になりすますということは難しいでしょう.
逆にいうとAuthorization Codeがワンタイムになっていない場合, 収集先でそのAuthorization Codeを自分のブラウザで利用することで"なりすまし"が可能になります.
他にもこまけぇこといろいろ考えたのですが現実的じゃないものが多かったので割愛します.
ではまた！