金利0無利息キャッシング – キャッシングできます

 | 

2012-02-14

OAuthにおける「クライアントサイドに対する認可」なのか「サーバーサイドに対する認可」なのか明確でない問題

15:10 | OAuthにおける「クライアントサイドに対する認可」なのか「サーバーサイドに対する認可」なのか明確でない問題 - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - OAuthにおける「クライアントサイドに対する認可」なのか「サーバーサイドに対する認可」なのか明確でない問題 - 金利0無利息キャッシング – キャッシングできます

ココらへんの問題について、適当に自分の考えを書いたりします。

個人的に、余計な権限がついてまわるようなOAuth使ってログインさせるサイトが多くて嫌だなーと感じているのだけど、それはそうとして置いといて。俺はいわゆるWebサイトについている「OAuthを使ったログインボタン」に実装上の問題があるケースというのはそんなに多くないと思っている。なぜかというとサーバーサイドに対する認可を求めているなら最初からCode Flow(response_type=code)を使えば良いから、わざわざImplicit Flow(response_type=token)を使う必要がない。だから問題が起こりやすいのは、OAuthによる認可が与えられたのがクライアントサイドなのかサーバーサイドなのかが曖昧になるような、OpenSocialアプリの類だったりとか、スマートフォンアプリだったりだとかではないかと思う。

クライアントサイドに与えられた認可を、サーバーサイドに流用するということについて、そのようなアプリケーションが「邪悪である」というコンセンサスが取れていない(あるいは取る必要があるのか)という問題を含んでいるのではないかと思う。

認可を与えた対象は誰?という問題

OAuth2.0のImplicit Flowというのは、こんな感じでAccess tokenを受け取ることが出来るわけです。

#以降の部分はサーバー側のアクセスログに残らない。例えば、GmailOAuthを使っているクライアントがあったとして、Implicit Flowを使えばAccess tokenが受け渡される相手をアプリケーションのみに限定することが出来る。この場合、メールを読むことが出来るのはアプリケーション(UserAgent)であって、そのアプリケーションの作者ではない。あなたのプライベートな情報を見ることが出来るのは、あくまでも認可を与えたアプリケーションであって、アプリケーション開発者はあなたのデータにアクセス出来ませんよ、ってことが実現できるのが嬉しいわけ。

例えばOAuthを使ったアプリケーションの開発者がいるとして、Aさんとしましょう。Aさんだと分かりにくいので小池さんとしましょう。

  • 小池さんの作る(サーバーサイドの)アプリケーションに対して認可を与えると、あなたの個人情報が小池さんのサーバーから読み取られたりといったそういう問題が発生する(わかりやすい)
  • 小池さんの作る(クライアントサイドの)アプリケーションに対して認可を与えた場合、あなたの個人情報が小池さんから読み取られるかどうかは、実装次第。
  • 小池さんに悪意があれば、やっぱり取得したaccess_tokenをこっそりサーバーに送ったり、クライアントサイドで受信したメールをサーバーに送って、メールを盗み見ることが出来てしまう。
  • しかし、小池さんがアプリケーションのソースを公開していて、信頼出来る人がそれを検証していて、各々のマシンでアプリケーションが改変されずに実行されているのであれば、小池さんがメールを盗み見ていないということが保障できる

地の底までに信用が落ちた小池さんであっても、適切な公開手順や第三者による検査を受けているのであれば、アプリケーション自体を信用することは出来る。

アプリケーションがどこで動いているのかは曖昧になっている

  • プログラムがどこで動いているのかは意識されなくなっている
  • もしくは、プログラムがどんな動作をするのかを、いちいち検証する人は(ユーザー全体からすれば)少なくなっている

人によってはクライアントサイドへの認可なのか、サーバーサイドへの認可なのか「そんな区別には大した意味がない」と言うかもしれない。大多数のユーザーはソース読んだりできないのだから単にサービス提供者であったり、アプリケーション作者を信用するかどうかという問題に帰結してしまう。ただ「曖昧になっているのをいいことに」クライアントサイドで動いているつもりが実はクラウド上で動作していてバリバリ個人情報送信されてました、みたいな状況はよろしく無いと思う。

  • 「どのアプリケーションに対して与えられたtokenなのかを検証する」という解決策だと、検証を忘れた際に脆弱性になる
  • バリデーションが必要な状況が発生したら、その状況そのものを疑うべき
  • access_tokenの値をサーバーに送ってしまうということは、結局サーバーサイドにも認可を与えちゃってるってことだよ。
  • あるいはクライアントサイドで取得した何らかの個人情報をサーバーに送るのであれば、それは結局サーバーサイドへの認可を必要としていると考えるべき。

それが必要なんであれば、最初からCode Flowでやればいいんじゃないの、以上、という話になる。クライアントサイドには完全なフルアクセスの許可を与えた上で、サーバーサイドにはアプリケーション毎に発行される一意の匿名idが取得できる、みたいな使い分けが出来ると便利なんじゃないかと思いました。

2012-03-14追記: 合わせて読みたい

心強いお言葉。

サーバーサイドとクライアントサイドの両方のComponentから構成されている場合、別々で登録しろ!

iOS版のPathはSSLの証明書エラーを無視している → 修正された

14:20 | iOS版のPathはSSLの証明書エラーを無視している → 修正された - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - iOS版のPathはSSLの証明書エラーを無視している → 修正された - 金利0無利息キャッシング – キャッシングできます

ココらへんの問題について

何人か言及してる人がいるのだけど

手順見ておかしいと気付く人は気付くだろうけど、これiPhoneの方に証明書を追加してない。

SSLを使って暗号化されている通信内容を解析するときには、中継するプロキシサーバーを「信用します」と端末に設定することで、SSLを使った通信でもキャプチャが出来るようになる。Pathのアプリは、そういった手順を取らなくてもSSLを使った通信をキャプチャ出来る状態になっていた、中間者攻撃を受けても警告も無く、通信を止めない状態であった。わざわざ証明書エラーを無視するような設定にしないと、こんなことにはならない。Android版の方は検証していない。

Pathの人にはTwitterとメールフォーム経由で送ってあるんだけど、今のところ返事がない。

2011-03-11 追記

特に返事ないけど version 2.1 (2011-03-08リリース) で修正された。


どういう脅威があるのか

信用出来ないWi-Fiアクセスポイントに接続するなどした場合に、Path内での通信内容が他人に盗み見られる可能性がある(iPhone側には何の細工もいらない)。信用出来ない回線を使わなければ、盗聴されるということは無いだろうから、直ちに危険というわけではない。SSLを使っていないアプリと同程度に危険。盗聴された場合は、Pathのメールアドレスとパスワードが知られうる。アドレス帳送る際にはアドレス帳の内容が第三者から知られうる。

ユーザーとメディアの無責任さについて

報道したメディアが、謝った、直った、良かった、みたいな感じになってるんだけど、現在進行形でおかしなことが起きてることについて総スルーしていて気持ち悪い。これは実装上のミスだろうから、アドレス帳を送っている件と直接は関係がない。なんだけど「We always transmit this and any other information you share on Path to our servers over an encrypted connection. It is also stored securely on our servers using industry standard firewall technology.」証明書エラーを無視していて盗聴可能であるのに、暗号化された接続と言ってしまっている。理解されやすい表層的な部分ばかり取り上げられて、本気で技術的におかしなことが起きていてもスルーされてしまう。

そもそも、これは「セキュリティ専門家」が「特殊なツールを使って」解析しないと分からないようなことだったのか?俺にはそんな風に思えない。本当にこっそり送っているのなら、分からないだろうけど、Pathってそういうケースではないよね。登録後に、特に何もしなくてもアドレス帳内からPathを使っている友人の一覧が推薦されたのを多くのユーザーが目にしてきたはずだ。人々はそれを受け入れてきたのか?仕方ないと思ってきたのか?不愉快だけどフィードバックされて来なかったのか?それとも謎の仕組みでサーバーにアドレス帳を送信せずに友人候補を出していると思っていたのか?

色んな課題がある

  • そもそもアドレス帳に入っている個人情報は誰のもの?
  • iOS側でアドレス帳の読み取りに対して許可を求めるべきなんじゃないの?
  • 人間関係のインポート/エクスポートを安全に行うにはどうすれば?
    • 電話番号のハッシュ値は無意味問題(元に戻せるから)
  • 非公開のつもりで登録したメールアドレスや電話番号が「検索可能」になっている問題
    • 「メールアドレス」や「電話番号」を非公開のつもりで登録してるのに、アドレス帳から探すAPI経由で特定出来る問題
    • サービスによっては検索を拒否する設定があるが、拒否できない場合がある
    • そのメールアドレスや電話番号とは紐付けたくなかったアカウントが意図せず紐付いてしまう
    • 場合によってはブルートフォースアタックで特定のユーザーのメールアドレスや電話番号が分かるだろう

ここらへんの問題については長くなるのでそのうち書こうと思う。

トラックバック - http://subtech.g.hatena.ne.jp/mala/20120214
 |