oauthで気持ちのいいアクセス制御を
Post on 15-Jan-2015
8.701 Views
Preview:
DESCRIPTION
TRANSCRIPT
OAuth で気持ちのいいアクセス制御をKousuke Ebihara
<ebihara@tejimaya.com>
Twitter 中毒のみなさんこんにちは
Twitter にはサードパーティの色んなクライアントやサービスがありますね
モバツイッター 携帯電話から Twitter を利用するための
サイト メール投稿がおこなえたり、連携している
画像投稿サイトに投稿した画像を表示できたりなどの多彩な機能を備える
OpenEBI
位置情報を飛ばして自分のルートを描いていくサイト（拙作）
Twitter への同時投稿が可能
ヌイッター ヌいたら報告するための Tweet ツール
（意味がよくわからないけど）
ただし、サービス終了済み
悪の親玉？違法性？
「こういう風に」のリンクを辿ってみた
http://takagi-hiromitsu.jp/diary/20080217.html
これは、他サイトであるところの「 Twitter 」 の ID ・パスワードの入力を促している。ここに、 Twitter の ID ・パスワードを入力してボタンを押すと、 ( 中略 ) 定型文の書き込み操作を行うという動作をする。しかし、 ( 中略 ) この動作は、実際にパスワードを入力した人の意図に反する動作となっているようだ。 このようなサイトを設置する行為は、不正アクセス禁止法違反に問われるおそれがあるのではないだろうか。
( 高木浩光＠自宅の日記 「 nwitter 」の違法性について考えてみる より引用 )
「 nwitter 」のサイトには「アカウント名やパスワードなどの情報は一切ヌいてません」と書かれているが、そういう問題ではない。 ( 高木浩光＠自宅の日記 「 nwitter 」の違法性について考えてみる より引用 )
そう、今まで紹介したサービスは利用者の ID ・パスワードを利用することで実現されています
Twitter の ID ・パスワードをサービスに預けることによるデメリット（利用者） Twitter を勝手に利用されてしまうかもしれ
ない （他のサービスと共通のパスワードを利用し
た場合）他のサービスを不正に利用されてしまうかもしれない
パスワードを生もしくは復号可能な状態にしておかなければならないため、サービスが SQL Injection Attack などへの脆弱性を抱えていた場合、パスワードの漏洩の危険がある
ID ・パスワードをサービスに預けることによるデメリット（運営者） 極めて重要な個人情報をセキュアでない
形で預かることになる パスワードは不正アクセス禁止法の「他
人の識別符号」にあたり、これを故意か事故かに関わらず公開することは、第四条の「不正アクセス行為を助長する行為の禁止」に抵触する可能性がある（三十万円以下の罰金）
OAuth 登場以前、Twitter の投稿 API を叩くための認証は Basic 認証しかありませんでした
Twitter 投稿用ライブラリなんかも、 Basic 認証を前提に組まれていることが多く、利用者の ID とパスワードを利用したサービスが蔓延しています
mixi のように API を提供していないサービスでも、サードパーティ製サービスがマッシュアップ（笑）したいがために、利用者のID とパスワードを入力させている例が存在します
つまり、サードパーティ製ツールなどの登場が予想されるサービスでは、利用者のプライバシー保護のためにID ・パスワードによらないAPI のアクセス制御が求められているのではないでしょうか
そこで颯爽と登場した OAuth
Twitter の OpenID 実装をおこなっていた Blaine Cook 氏らが、必要としていた API アクセス権委譲に関するオープンなプロトコルが存在していないことに気づき、新たなプロトコルを作成するためのプロジェクトを開始した
2007 年 10 月に OAuth Core 1.0 の草案がリリースされた
Flickr や Twitter や Google や米 Yahoo など多くのサービスで利用されている
OAuth を使うとどうなるの？ まずは使ってみよう！ 以下の URL に突貫で作った OAuth 対応の Twitter クライアントがあるので、アクセスしてみてください！
http://co3k.org/twitter/
OAuth を体感 サイトの注意書きをよく読んで、ボタン
をクリックする
OAuth を体感 Twitter のページに行き、「 ubetter っつーア
プリが投稿したがってるけどどーすんの？」と聞かれるけど……許可しちゃおうか？
OAuth を体感 ……の前に、ちゃんと本物の Twitter の
サイトかどうか確認しましょう！
OAuth を体感 気を取り直してボタンプッシュ
OAuth を体感 うべー
見てわかるとおり、OAuth による認可は、認証に使われる ID やパスワードなどの情報を必要としない
認可と認証の違い 認証は「その人であるかどうか」
のチェック（ Authentication ） 認可は「その行動が許されている
かどうか」のチェック（ Authorization ）
認可とは OAuth (pronounced “Oh-Auth”),
summarized as “your valet key for the web," OAuth （オー・オウスと読みます）は、簡単
に言えば、「ウェブにおけるバレットキー」のようなもので、
(For immediate release: OAuth Core 1.0 Specification released at Internet Identity Workshop より引用 )
バレットキーとは バレットキーとは、例えば、ホテルのバレットパーキング係にキーを渡して自動車を預ける場合に使用されるキーであり、そのキーでは、ドアの解錠やエンジンの始動はできるが、トランクやグローブボックス等の収納コンパートメントを開けることができない。
(http://www.j-tokkyo.com/2006/E05B/JP2006-225975.shtml より引用 )
つまりどういうこと？ Basic 認証のために ID とパスワードを教えるということは、相手に全権限を与えてしまうことに等しい
OAuth では一部権限のみを許可するトークンを渡す形をとっている Twitter では「読み書き可」「読みのみ可」
の二通りの権限が選択できる トークンには有効期限を設けることができる
リダイレクトしまくりでキモイこいつら中でなにやってんの？
つ
1. リクエストトークンの取得
サイト
ツール
アタシツール歳？２３
まぁ今年で２４彼氏？
まぁ（中略）いいから
トモのリソースにアクセスさせて
みたいな
うーん……ちょっと聞いてみるから
トモ連れてきてよ
a. リクエストトークン要求
b. リクエストトークン発行
2. ユーザの承認を得る
ツール連れてきてやった
みたいな
c. ユーザをサービスプロバイダに案内する
サイト
あなた本物のトモさん？本当にこの人にアクセスさせて大丈夫なんだね？
d. ユーザを認証し、同意を取る
トモさんがいいって言うなら仕方がない。
e. ユーザをコンシューマに案内する
3. アクセストークンの取得リクエストトークンはあくまで承認を得るためのものなので、リソースにアクセスするためには別のトークンを用いる。
サイト
ツール
アタシツール
（中略）トモのリソースに
アクセスさせてみたいな
仕方がないなあ。ほら、鍵だよ
f. ユーザ承認済みのリクエストトークン付きでアクセストークン要求
g. リクエストトークンを検証し、アクセストークンを発行
4. リソースへのアクセス
サイト
ツール
h. アクセストークンを使ってリソースを要求アクセス
i. アクセストークンを検証し、リソースへのアクセスを認める
補足 トークン付きリクエストは署名される
HMAC-SHA1 (Twitter はこの方式のみ対応 ) RSA-SHA1 PLAINTEXT (非署名 )
なんかすごそうじゃん。じゃあとりあえず OAuth 使っておけばよさげだね
残念ながら、OAuth のプロトコルにはSession Fixation 脆弱性が存在します
OAuth に潜む脆弱性 2009/04/23(海老原の誕生日！ ) 、ソー
シャルエンジニアリングの手法によりセッションを固定化できるという脆弱性がレポートされる
ID, パスワードや各種トークンやシークレットを盗まれるといった類の脆弱性ではない
プロバイダ側で対策が可能である
どういう脆弱性か 通常のフロー
コンシューマの利用開始ユーザ
リクエストトークンを発行
アクセストークンを発行し、
リソースへアクセス
プロバイダにリダイレクト コンシューマにリダイレクト
どういう脆弱性か 攻撃フロー
ユーザ
コンシューマの利用開始攻撃者
リクエストトークンを発行
承認されたリクエストトークンを使い、
アクセストークンを発行し、
リソースへアクセス
プロバイダにリダイレクト
リクエストトークンを承認
ユーザに URL を踏ませる
対策方法 承認されてないリクエストトークンでアクセストークン
を要求した時点でリクエストトークンを無効にする アクセストークンの要求に回数制限を設ける 同じリクエストトークンを使用して複数箇所からアクセ
スがあったと思われる場合、リクエストトークンを無効にする
コールバック URL をパラメータから渡すのではなく、登録制にする
Twitter が採っている対策 コールバック URL を用いず、コンシューマが使うキー
をユーザに手入力させる Yammer が採っている対策
対策方法 ただし、 OAuth プロトコル自体の修正
はまだおこなわれていない 現在どう対策するべきか協議中 近々修正された仕様が公開されるとかどうと
か アイディアがあれば是非提案してみてくださ
い！
OpenPNE 3.1 とOAuth
OpenPNE3 では OAuth 対応が求められている
OpenSocial WebAPI
この WebAPI を利用したサードパーティ製ツールを増やしていきたいですね
OpenPNE3 の OAuth （仮）
管理画面から特定のアプリケーションを登録、認可（ほぼすべての SNS内リソースへのアクセス許可）
SNS 全体に関わるアプリケーション：OpenSocial など
コミュニティから特定のアプリケーションを登録、認可（コミュニティに関する SNS内リソースへのアクセス許可）
コミュニティに関わるアプリケーション：コミュニティ間のチャットなど
個人で特定のアプリケーションを登録、認可（その個人がアクセスできる SNS内リソースへのアクセス許可）
OpenPNE3 は6月中旬リリース（予定）の 3.1.1 で OAuth に対応します
これで OAuth がぐっと身近になりますね！
6月中旬が待ち遠しいです！
でも OAuth ってなんだか難しそう……
そんなことないです（コンシューマは）
いろいろライブラリが揃っている（コンシューマは）
情報もそれなりに出てきている（コンシューマは）
OAuth のプロトコルはかなりシンプルなので、ライブラリがなくても割となんとかなりそうなくらい敷居は低いはず（コンシューマは）
ということで、Twitter もしくはOpenPNE3 向けにOAuth アプリ作ってみませんか？
質問タイム
top related