idcon mini :Vol.3 - Covert Redirectの話はまだ終わってない 


		私の理解浅い部分あるです

- [http://idcon.doorkeeper.jp/events/11429](http://idcon.doorkeeper.jp/events/11429)

- [http://oauth.jp/blog/2014/05/07/covert-redirect-in-implicit-flow/](http://oauth.jp/blog/2014/05/07/covert-redirect-in-implicit-flow/)

- [http://oauth.jp/blog/2014/05/09/what-happens-when-oauth2-code-leaked/
](http://oauth.jp/blog/2014/05/09/what-happens-when-oauth2-code-leaked/)

- [http://oauth.jp/blog/2014/05/08/covert-redirect-and-non-30x-redirects/](http://oauth.jp/blog/2014/05/08/covert-redirect-and-non-30x-redirects/)


# @ritouさん #
- [http://www.slideshare.net/ritou/idcon-mini-vol3covertredirect](http://www.slideshare.net/ritou/idcon-mini-vol3covertredirect)

- これは安全！ は本当そうかな？ともやもやを解消したい。
- Open Redirectorをredirect_uriに指定されてしまう
- redirect_uri をexact matchさせないauthz serverがある

- Github は hostしかみてないのでダメ(@nov)
- FacebookはDraftの若い頃からつくっているからひろまっちゃって今更変えられない( @nov)
    - ただし、オプション(Advanced)でexact match 指定できる
- sessionとブラウザクッキーを紐づけてチェックしたとしても、攻撃者が正規に取得したcodeを被害者に送りつけてアクセスさせる攻撃が可能(@nov)
    - codeをclient_idに紐づけておくとどうなの？
    - 攻撃者と被害者が同じClientだったらだめ 
- Native AppとWebは client_id を分けないといかん (Serverではtokenとclient_idを紐づけること)
- application_typeはGoogleの要求で仕様に入った(@Nat)
- client_id  + applicaton_type にトークンを紐づける(@Nat)
- FBだと、 Native AppとWebでclient_idを分けてないので危険(@nov)

# mixi hack ....

- [http://d.hatena.ne.jp/ritou/20131117/1384677989](http://d.hatena.ne.jp/ritou/20131117/1384677989)
- mixi は Client のstateチェックを信用していない(@ritou)
- server_state
- 攻撃者が最初にserver_stateを取得したAuthReqを、被害者に踏ませるとダメ
- Bearerなので漏らすなよ。前提が崩れる(@Nat) 
- 攻撃者が正規に作ったAuthReqを被害者に踏ませて、AuthResを攻撃者に戻されたら、何をやってもだめ(っぽい)
    - AuthReqとブラウザセッションの組み合わせはClient的には正しい
    - ブラウザセッションはAuthzでは確認しようがない
- OAuth2はredirect_uriのQueryは自由(ConnectはQueryまでExact Match)
- リクエスト署名。OAuth 1.0 はクライアントシークレットが漏れない限り大丈夫。Twitterの実装がクソなだけ(@ritou)
- OAuth 1.0 + Twitterが Covertの元祖。
- Artifact Binding (リクエストパラメータをClinet->Serverで事前に送る。 Connect のRequest Object+署名)だとredirect_uriを書き換えるのは無理。

# Google + JS

- [http://d.hatena.ne.jp/ritou/20130302/1362165981](http://d.hatena.ne.jp/ritou/20130302/1362165981)
- Google+ PostMessage で返す。チェックがoriginだけ、とか。（@ritou） 
- アタッカー：正規のクライアントの配下にJSを仕込んだページを用意して、ImplicitでJSが受けたトークンをそのページに飛ばさせる。
- ダメ。
- OpenID 2.0の情況に近い。
- Googleは厳しいところは厳しいが、緩いところは緩い。(@ritou)
- ConnectのPostMessage拡張はどうだったっけ... 

    


# OAuth Proof of Possesion 

- [http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00](http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00)
- これでもだめっぽい...(@nov)

# OpenID 2.0 Migration

- ID Tokenに入っている、2.0 Identifier を、 OpenID 2.0 Discovery して、jwks_uriを入手
- 署名がそれで検証できたら、Issuerが同じ、ということ
- Connectでも、ドメインが異なったら同じようにやる。MSとか(@nov)
- RealmをClientRegでやるか(@Nat)
- 一つのクライアントに対して複数Realmがあり得るケース。。。。。企業買収とか(@nov)
- 「Realms」の登録？(@Nat) さすがにExact Matchでしょう(@nov)
- 受け取った側が何をしないと行けないか？を考えるべき(@Nat)
- ドメインが変わったら諦めよう！(@nov)
- OpenID 2.0 はRP側でライブラリを理解して導入している人はいない。ライブラリを入れたら動くもの、的(@nov)
- live.com ->  www.microsoftonline.com 
- 野良Connect OPがDyna Regやりだしたら...
- まとめると「OpenID 2.0とConnetのドメインがいっちだったら鍵チェックなし。ちがったらチェックしろ。」

# まとめると

- AuthzServer : redirect_uri exact match
- Client: No Open Redirector 
- Clientが5000超えたら、互換とって実装するのは不可能(@nov)
- 改善したいなら別のエンドポイントを用意して行く(@nov)