OAuth.jp

この記事は、先ほど書いたこちらの記事の訂正版です。

記事に入る前に、まずは全シンガポールにお詫び申し上げますm m

さて、Covert Redirect についての説明は…超絶取り消し線はいりまくってる前の記事を読んでください、でいいでしょうか？

で、訂正分だけ以下に。

Fragment Handling in Redirect

宮川さんが記事にしてますね。

英語だけど。

で、まぁ要するに、(Modern Browser は) 30x リダイレクト時にリダイレクト元に付いてた URL fragment をリダイレクト先にも引っ付ける、と。

fragment は server-side には送られないけど、クライアントサイドではリダイレクト先に引き継がれる、と。

試しに http://www.idcon.org/#foobar にアクセスすると、http://idcon.org/#foobar にリダイレクトされるかと思います。

www.idcon.org のサーバーには #foobar の部分は送られませんが、http://idcon.org/ に load される client-side の JS からは、#foobar にアクセスできます。

なので、Covert Redirect のケースでも、open redirector をつかって最終的に被害者がリダイレクトしてくる endpoint に攻撃者が JS を仕込んでそれを自分のサーバーにでも送るようにしておけば、access token が漏洩します。

もちろん先ほどの記事にあるように、Authorization Code が漏洩するケースもありますが、open redirector の実装詳細に依存しない分、Implicit Flow において fragment に含まれる access token が漏洩する方が可能性としては高いでしょう。

訂正

リダイレクト時の fragment の扱いを勘違いしていたため、本記事全体訂正します。

細かく訂正いれてると分けわかんなくなってきたんで、新しい記事書きました。

ゴールデンウィークまっただなかに Twitter で海外の ID 厨から袋だたきにあってたので、もうこの問題は片付いただろうとすっかり油断してた「Covert Redirect」の件ですが、日本でもゴールデンウィーク明けてバズりだしたので、一旦問題を整理した方がよさそうですね。

事の発端

Wang Jing さんていうシンガポールの大学院生が、こんなサイトを公開すると共に CNet はじめ各種メディアが取り上げたのが、バズりだした発端のようです。

前提知識

OAuth 2.0 や OpenID Connect だけでなく、OAuth 1.0 や OpenID 1.0/2.0 や SAML なんかでも、2つのサービスの間でリダイレクトを経由して、Access Token や ID Token などのいわゆる “Security Token” の授受 が行われます。

Covert Redirect の問題は本質的にはこれら全てに影響しますが、各仕様一個一個見て行くといろいろ疲れるので、ここでは OAuth 2.0 に絞って話をすすめましょう。

OAuth 2.0 では、まず Client が End-User の UserAgent を Server の Authorization Endpoint というところにリダイレクトします。よく Twitter とか Facebook の ID で外部サービスにログインするとき、一度 Twitter や Facebook にリダイレクトして、同意画面表示されますよね？あれです。

で、みなさん何も考えず熟慮の結果、同意ボタンを押すじゃないですか。そして、元のサイト (= Client) に戻って来る、と。

OAuth 愛好家の間で “OAuth Dance” なんて呼ばれてるアレですね。

で、今回の話は、その “OAuth Dance” 中の話 です。

昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。

僕もちょっとそういうケース見かけました。

なんか Yahoo! Japan がポカしちゃったの？とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。

が、今回のケース、Yahoo! は全く悪くない！
プライバシーフリークはどうかと思うがな！！

では早速、今回起こったことを、振り返ってみましょう。

Yahoo! API にアクセスできなくなった

Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用の *.yahooapis.jp というドメイン。

Yahoo! Wallet はよく知らないけど、YConnect だと userinfo.yahooapis.jp っていうドメインがあって、そこにアクセスできなくなった。

ただし、API サーバーが止まったとかそういうのではなく、API にリクエスト投げる側での、SSL エラーによって。

@nov です。

JWE はまだまだ変わりそうな気がしてしばらく最新仕様への追随を怠っていたのですが、先日こんな pull request をいただいたので、以下の2つのライブラリの JWE 実装を、JWE draft v17 に追随させました。

• Ruby json-jwt gem
• PHP JOSE

ところでその pull request 内でのやり取りで知ったのですが、Xbox One ってのが JWE を使ってるらしいですね。

他にも Production で JWE 使ってるとことかあるんでしょうか？

今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。

Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ

— Ruby on Rails News (@RubyonRailsNews) September 25, 2013

前提条件

Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。

この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代わりに暗号化してるけど、ここで述べる問題に関してはsignedなのかencryptedなのかは関係ないのでその点は無視していいです。

「current user identifierを含むSigned JSONをcookieに入れてるのと同じなので、OpenID ConnectのID Tokenがcookieに入ってるようなもんだと思えばいい」と言えば、#idcon に来たり定期的にOAuth.jp読んだりしてる人には通じるだろうと期待します。

問題点

server-sideではstate管理しないので、当然remoteでセッションの無効化はできません。 つまりログアウトしてもsession cookieのtoken自体は無効化されません。

これを確認するには、サイトにログインしてCookie Headerから_foo_cookieってやつ見つけ出してその値をコピーして、CharlesでRequest Cookie Headerの_foo_sessionの値を常にそのコピーした値に書き換えてやるようなRewriteルールを設定してやって、サイトからログアウトしてみるとよいです。 通常server-sideでsession管理してるサービスだとこれでログアウトされるけど、CookieStoreを使ってる場合はこの条件の元ではログアウトしてもログイン状態のままになります。

でもまぁこれはCookieStoreの仕組み上どうしようもないのです。

問題は、session cookieが無効化できないのに、それが永遠に有効であること。 FBとかY!Jとかでやってる「パスワード変更したら既存のsessionが無効になる」ってのはRailsは一切面倒見てくれないので、パスワード変えても漏洩したsession cookieは有効なままです。 なので、ひとたびsession cookieが漏れたら、完全にアウト。 なにやってもアカウント乗っ取られたまんま。永遠に。