OAuth.jp

昨日の続き。「ソーシャルゲームなんて3000万人の特殊な人しかやってない」という意見もあるようなので、今日は iOS アプリ版。

登場人物

• iOS SDK 出してるプラットフォーム
• iOS SDK と連携するプラットフォームの公式 iOS アプリ
• プラットフォーム上で "まっとうな" アプリを運営してる攻撃者
• 攻撃者が自作した攻撃用アプリ
• iOS SDK 使って開発された被害アプリ
• あいかわらず無邪気な被害ユーザ

前提

プラットフォームが提供する iOS SDK は、

1. プラットフォームが指定するカスタムスキーマ (ex. “xyz-connect://”) で始まる URI にアクセスすることで
2. プラットフォーム公式 iOS アプリに access token 取得のフローを delegate し
3. 公式アプリが被害アプリの指定するカスタムスキーマ (ex. “foobar-rowial://”) で始まる URI にユーザーを戻すことで、アプリに access token を返す。

被害アプリは、

1. iOS SDK から受け取った access token を自身のバックエンドサーバに送り
2. バックエンドサーバはプラットフォームが提供する Profile API (GET /me とか) にアクセスして
3. レスポンスに含まれる user_id をもとにユーザを認証する。

シナリオ

1. 攻撃者はプラットフォームが指定するのと同じカスタムスキーマで delegate を受け取る攻撃用アプリを自作する (なり誰かから買うなり..)
2. 攻撃者は自分の iPhone/iPad に攻撃用アプリをインストール (xcode 経由だと、Apple の承認必要ないんですよね、たしか？)
3. 攻撃者は自分が運営する "まっとうな" なアプリの DB から被害ユーザのアクセストークンを取って来て攻撃用アプリに埋め込む
4. 攻撃者は被害アプリを起動して “なんちゃら ID でログイン” とかいうボタンを押す
5. 被害アプリはプラットフォーム攻撃者が自作した攻撃用アプリに delegate 開始
6. 攻撃用アプリは被害ユーザのアクセストークンを被害アプリに返す
7. 攻撃者は被害ユーザのアカウントで被害アプリを使う

対策方法

プラットフォームの iOS SDK は “response_type=token code” に対応する。

被害アプリは、"response_type=token code" を使い、サーバーサイドへは access token ではなく authorization code を送る。(そしてサーバーサイドでは client authentication して code を token と交換する)

ただいかんせんプラットフォーム側の iOS SDK が対応してくれなかったり、既にアプリを公開していて古いバージョンもサポートしなければならなかったりすることもあるので、そういう場合はバックエンドサーバーで対応。

被害アプリのバックエンドサーバは、どうしてもアプリ側から access token を受け取らざるを得ないのであれば、昨日の記事と同様に access token 発行先アプリが自身であることを確認する。

追記

いくつか気になるtweetがあったので、載せときます。

@7032 「そもそもそれ認証関係お任せライブラリでは無いから、勘違いするとこういう目にあうよ。」という話です。

— OAuth.jp (@oauthjp) February 9, 2012

@7032 コンポーネントというのがiOS SDKのことを指してるなら、それはちゃんと認可リクエストも送ってるしそのレスポンスも受け取ってるので、OAuthの仕様の範囲内では正常に動作しています。受け取ったトークンが、そもそも認証のために使えるものである保証が無いというだけです。

— OAuth.jp (@oauthjp) February 9, 2012

。登場人物

• OAuth 2.0対応してる某ゲームプラットフォーム
• 某ゲームプラットフォーム上で占いゲームを運営してる攻撃者
• 某ゲームプラットフォーム上で運営されてる農園ゲーム（= 被害アプリ）
• 某ゲームプラットフォーム上で無邪気に遊んでる被害ユーザ

※ 念のため、今回の話は特にゲームに限った話ではない。

前提

某ゲームプラットフォーム、農園ゲーム共に、XSS とか CSRF とかセッションハイジャックされるような脆弱性はない。

農園ゲームはプラットフォームが発行するAccess TokenをOAuth 2.0のImplicit Flowを使って受け取り、同じくプラットフォームが提供するProfile API (GET /me とか) にアクセスして、レスポンスに含まれる user_id をもとにユーザを認証している。

攻撃者は占いゲームのDBから任意のAccess Tokenを取得可能。

シナリオ

1. 被害ユーザが占いゲームに登録 (= 占いゲームに対するAccess Tokenが発行される)
2. 攻撃者が農園ゲームにアクセス、Authorization Flow開始
3. 攻撃者が某ゲームプラットフォーム -> 農園ゲームへのRedirect Responseを中断させる
4. 攻撃者がFragment中のAccess Tokenを占いゲームのDBから持ってきた被害者のAccess Tokenに置き換え
5. 農園ゲームは受け取ったAccess Tokenをもとに、攻撃者を被害ユーザとして認証
6. 攻撃者が被害ユーザとして農園ゲームで遊ぶ

対策方法

農園ゲームの開発者は、受け取ったAccess Tokenが農園ゲームに対して発行されたものであることを確認すること。占いゲームに対して発行されたAccess Tokenを受け入れないこと。

プラットフォームがFacebookの場合なら、以下のリクエストを行うことで、Access Tokenがどのクライアントに発行されたものかを検証可能。

GET /app
Authorization: OAuth replace_with_your_access_token

急募 : 他のプラットフォームの場合の対応策

参考文献

• 単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
• OAuth 2.0 Implicit Flowをユーザー認証に利用する際のリスクと対策方法について #idcon

昨晩、IETF OAuth WG ML で、OAuth 2.0 Core & Bearer の2つの仕様が IETF Last Call に入ったことが通知されました。

http://www.ietf.org/mail-archive/web/oauth/current/msg08285.html

http://www.ietf.org/mail-archive/web/oauth/current/msg08286.html

今後は IETF のルールに乗っ取って、RFC 化までの作業が進められます。

ちょうど以下のメールで IETF Last Call から RFC 化までの流れが説明されていたので、翻訳しておきます。

http://www.ietf.org/mail-archive/web/oauth/current/msg08292.html

1. IETF Last Call, which lasts two weeks. This is essentially your last opportunity to provide feedback!

IETF Last Call では、2週間で結論が出る。本質的にこの期間がフィードバックを行う最後のチャンスである。

2. During IETF Last Call, the documents will be reviewed by several cross-area teams within the IETF, including folks like the "GEN-ART" review team and the AppsDir. We'll expect at least some feedback from those teams. And at this stage anyone in the Internet community can provide feedback, too.

IETF Last Call 期間中、仕様書は "GEN-ART" レビューチームや AppsDir を含む IETF 内の複数エリアのチームにレビューされる。少なくともこれらのチームからは何らかのフィードバックが得られるであろう。もちろんこのステージでも Internet community の全員にフィードバックを行う権利がある。

3. After IETF Last Call, this WG's document editors will work to address any feedback we've received.

IETF Last Call 後、Working Group 仕様書編集者は受け取ったすべてのフィードバックに対応する。

4. The documents will then be scheduled for disussion during an IESG telechat. Before the telechat, all the members of the Internet Engineering Steering Group will review the specs and also provide feedback. If there are "DISCUSSES" and "COMMENTS" lodged then the document editors will need to address those (often in concert with the WG chairs). If some of those issues are substantive, the editors and chairs might bring those issues back to the WG for more discussion.

その後、仕様書は IESG の電話会議でのディスカッションにまわされる。この会議の前に、全 IESG メンバーがレビューおよびフィードバックを行う。"DISCUSSES" もしくは "COMMENTS" が発生した場合は、エディターが (おそらく WG チェアと共に) これらに対応する必要がある。もし問題が大量に発生した場合は、エディターとチェアは再び仕様を WG に差し戻し、WG 内でさらなる議論を行うこともある。

5. Assuming the documents are approved by the IESG, they will then be handed off to the RFC Editor team for final copy editing, proofreading, reference checking, etc.

仕様書が IESG に認可されると、RFC Editor チームの手によって最終的な編集、校正、リファレンスチェックなどが行われる。

脱デルデル詐欺！

OAuth 2.0 Core draft 22 & Bearer draft 11 の翻訳版を、OpenID Foundation Japan 翻訳WGのページで公開しました。

12月〜1月あたりにOAuth 2.0のRFC化も予想されており、これからOAuth 2.0対応APIも増えてくると思います。この翻訳版が、みなさんの参考になれば幸いです。

また、翻訳活動に参加していただいた12名の有志のみなさん (翻訳版の最後の方に翻訳者リストあり)、おつかれさまでした！

Core翻訳版はこちら。

The OAuth 2.0 Authorization Protocol

Bearer翻訳版はこちら。

The OAuth 2.0 Authorization Protocol: Bearer Tokens

@nov です。

先日こちらのサイトでメンバー募集した OAuth 2.0 翻訳プロジェクトですが、26日に Kick-off して27日から実際に翻訳活動をスタートしました。

[Core] https://github.com/openid-foundation-japan/draft-ietf-oauth

[Bearer] https://github.com/openid-foundation-japan/draft-ietf-oauth-v2-bearer

11月末の公開に向けて、2〜3週間は毎日少しずつ翻訳が進みます。

しかし、OpenID Foundation Japan の Github Organization メンバーが、いつのまにか20人超えていてびっくりです。

@nov です。

OAuth 2.0 も draft 22 を迎え、RFC 化も目の前に迫っています。

いまこそ

 OAuth 2.0 Core & Bearer を

 翻訳するときではありませんか！

ということで、以下の2つを翻訳するプロジェクトを開始します。

The OAuth 2.0 Authorization Protocol - draft-ietf-oauth-v2-22

The OAuth 2.0 Authorization Protocol: Bearer Tokens - draft-ietf-oauth-v2-bearer-09

このプロジェクトは OpenID Foundation Japan 翻訳・教育 Wroking Group の活動として、有志の参加者数名で進める予定です。

具体的には、参加者を Core と Bearer の2グループに分け、各自が3日に1度くらい翻訳して、残りの2日は他の人の翻訳のレビューをするというのを、翻訳終了（Coreが2〜3週間くらい、Bearer は1〜1.5週間くらい？）続けようかと思っています。

が、メンバーが足りません！

現状参加予定は @phr_eidentity、@bkihara、@nov の3名です。

3人だと、ちょっとしんどい。。。

そこで、協力者大募集です！

Kick-off は 10/26、都内のどこかで集まって、分担割り振ってから飲みましょう。

ご協力いただける方は、Twitter で @nov に Mention いただけるとうれしいです。閉め切りました。

以上、宣伝でした m_ _m

[追記]

@ritou と@kthrtty が参加！引き続き協力者モトム :)

[追記2]

@konfoo と @bucchi76 と @kurumai と @bkihara の同僚の未成年も参加。

人数も9人になったので、閉め切ります。

ありがとうございました :)

OpenID Foundation Japan の Evangelist としての初仕事で、Mashup Award #7 の Mashup Caravan & Meetup in Kyoto というイベントで話してきました。

Mashup Award に参加する方々に向けて、20分で OAuth 2.0 と OpenID Connect の概要を話すということで、OAuth 2.0 は draft 10 に絞って、OpenID Connect は技術的な話を一切割愛してます。

このスライドの最後のページにあるリンク集は、翻訳版の仕様とか僕のいままでのスライド一覧とかサンプルコードとかいろいろあるので、Mashup Award で OAuth 使う人は OAuth 1.0 / 2.0 関わらず参考にしていただければうれしいです。

あと、当日宣伝するの忘れてましたが、Identity 界の重鎮の皆様が虎視眈々と京都でイベントやる機会を狙っておられますんで、ぜひ京都在住の OpenID / OAuth あたりに興味ある方は、OpenID/OAuth in Kyoto の Facebook Page を Like していただければと思います。Fan が100人超える頃には、きっと Identity 界の重鎮が京都に勢揃いするはず！

ps. Mashup Award のオフィシャルブログで、当日の様子をご覧いただけます。

#MA7 Mashup Caravan & Meetup in Kyoto の報告！ - Mashup Awards 7 お知らせブログ

@nov です。

この度 OpenID Foundation Japan の Evangelist になりました。

今後は今まで以上にいろいろイベントとかで話させていただきます。

よろしくお願いします :)

2011/10/01、Facebook が認証まわりの API 仕様を変更します。結構大きな変更点の為、Developer としても、FB Canvas アプリもしくは Facebook Connect サイトの1ユーザーとしても、いろいろ混乱を経験する可能性もあるでしょう。

この記事では、大混乱が起こる前に、実際の変更点とDeveloper としてできることをまとめます。

変更点1

Graph API 以前に使われていた "fb_sig" や "fb_sig_session_key" といったパラメーターを使った認証方式が、一切使えなくなります。これにより、古い認証方式を使っている Facebook Canvas アプリおよび「Facebook ID でログイン」対応サイトで、ユーザーの認証ができなくなります。

これらのアプリは Graph API 以降に登場した OAuth 2.0 ベースの認証方式に切り替える必要があります。Canvas アプリなら Signed Request、Facebook Connect サイトであれば Facebook JS SDK の最新版を使うようにしてください。

変更点2

Graph API 以後のOAuth 2.0ベースでの「Facebook ID でログイン」に対応していたサイトでも、JS SDK がセットする Cookie に含まれる Access Token を利用しているサイトでは、Cookie に Access Token が含まれなくなるため、不具合がでる可能性があります。

<fb:login-button> もしくは Facebook JS SDK の FB.login() を使っているサイトはこれに該当するため、サーバーサイドでのライブラリアップデートやコード変更などが必要になるでしょう。

Developer としてできること

日本国内では Graph API 以前の Facebook API を利用していた方は多くないと思いますが、もしいた場合は、お使いのライブラリが既にメンテナンスされていない可能性が高いです。Ruby でも Facebooker というライブラリが古い Facebook API 用に存在しますが、既に1年以上アップデートがありません。そのようなライブラリを使っている場合は、違うライブラリに移行するべきでしょう。DEADLINE が 2011/10/01 なので、いますぐ対応を開始することをお勧めします。

Graph API 以降の認証方式を使っていた場合は、コードの変更が必要かどうかは実装依存のため、ひとまず Facebook Developer Apps から該当アプリ（もちろんテスト環境用のやつね）を選択し、Advanced タブの Migrations の（たぶん）一番下にある「OAuth Migration」を Enabled にしてみてください（スクリーンショット参考）。すると該当アプリでは 2011/10/01 以降と同様の動作を確認できるので、不具合の有無を調べましょう。不具合があれば、ライブラリのアップデートなどが必要になるでしょう。

Developer じゃなかったら？

例えば僕は Ustream にログインするのには Facebook アカウントを使っています。Slideshare もそうです。さすがにこれらのサイトは混乱無く OAuth Migration を終えてくれると信じたいですが、万が一のこともありますよね。

そういう場合、もしそのサイトが「Twitter ID でログイン」とか「OpenID でログイン」に対応していれば、Facebook ID 以外でもログインできるようにしておくことをおすすめします。

まぁ古くから Facebook と連携していて、最近アップデートされてなさそうなサービスの場合は ... 人生あきらめも重要です。

OpenID Connect の OP & RP 用の RubyGem をリリースしました。

https://github.com/nov/openid_connect

同時にサンプル OP サイトも公開しました。

サイト: https://openid-connect.herokuapp.com/

ソース: https://github.com/nov/openid_connect_sample

サンプルサイトに Facebook / Google ID でログインすると、まず OAuth Client の登録を要求されます。

OAuth Client を登録すると、以下の様に各 response_type ごとの Authorization Flow を開始するボタンが表示されます。

とりあえず OpenID Connect の UserInfo Endpoint にアクセスしたい場合は、token を選ぶのが一番手っ取り早いでしょう。

Access Token を取得したら、以下のように UserInfo Endpoint にアクセスしてみてください。

https://openid-connect.herokuapp.com/user_info?access_token=YOUR_TOKEN

こんな感じで JSON レスポンスが返ってくるはずです。

仕様の詳細はまだ把握しきれてないけど、とりあえず OpenID TechNight in Kansai にサンプル間に合った！

今後も 12/1 の OpenID Summit in Tokyo に向けて、徐々に機能追加していきます。

pull request 大歓迎♪