Google、WebViewからのOAuth認証リクエストをブロックへ 17
ストーリー by hylom
複数アカウント使いが面倒臭くなりそう 部門より
複数アカウント使いが面倒臭くなりそう 部門より
あるAnonymous Coward曰く、
GoogleがGoogleアカウントにおけるOAuth認証について、利便性とセキュリティ強化のために仕様変更を行うことを明らかにした。具体的には、今後数ヶ月内にいわゆる「WebView」など、アプリケーションにWebブラウザの機能を組み込むためのコンポーネントからのOAuthリクエストを受け付けないよう変更するとのこと（Google Developers Blog）。代わりに、端末のWebブラウザ経由で認証を行う手法が推奨されている。
WebViewでのログインでは、アプリ毎にGoogleのログイン画面にアクセスしてアカウント名やパスワードを入力する必要があった。いっぽう、端末のWebブラウザ経由で認証を行うことで、アプリ毎にログインを行う必要がなくなり、一度Webブラウザでログインすればアプリ毎のログインは不要となる（ただし確認画面は表示される）点がメリットだとされている。
WebViewを使ったログインでは、以前から悪意のあるアプリがログイン画面を偽造してアカウント名やパスワードを盗み取る可能性が指摘されていた（OAuthの認証にWebViewを使うのはやめよう）。
意味あるか？ (スコア:1)
まず「WebViewからの認証がブロックされた」ことを開発者でなくユーザーが理解しないとほとんど意味がない
たとえば悪意あるアプリがWebView経由でGoogleログインに偽装した画面を表示し、GoogleのIDとパスワードを剽窃する行為を防ぐには「WebViewとはどんな画面か」「そこにGoogleのID等をいれてはいけない」という事情をユーザー側が理解しないと結局防げないだろう
真っ当なアプリがWebViewを使わない仕様に変わったところで、それがどういう事情に根ざしてるかユーザーが理解しないでいれば、結局はID剽窃目的のアプリのカモにされうる、というリスクは殆ど変わらないわけだ
# この辺はTwitterのクライアントアプリがBASIC認証が禁止されてoAuthになったときの状況にかなり似てると思う
更に言うならブラウザから認証させるにしても「偽のブラウザ画面」を用意されたら割と騙されるよね
まあ偽のブラウザ画面を用意させる手間の分だけマルウェアが作りにくくなると思うけど、それはどこまで効果があるのか……
と、考えるとそもそも認証基盤そのものを抜本的に変更しない限り、この問題はいつまでも続くと思うなぁ
Re:意味あるか？ (スコア:2)
地道に習慣を根付かせていくんじゃないですかね。
わかりやすいルールであれば、より根付きやすい。
ブラウザ経由であれば、一般的なブラウザ利用上の理解が通用するわけで、別途ルールを覚える必要がない。
サイト側が実施する従来からのセキュリティ上の配慮にしたって、必ずしもユーザーに広く理解されているとは限りませんよね。
中間者攻撃でログインフォームが改竄される可能性があるからと、サイトはログインフォームの段階からHTTPSで用意していても、理解のないユーザーは、HTTPアクセス時に改竄で挿入された偽ログインフォームを使ってしまうかもしれません。
偽サイトによるフィッシングが判別しやすいようにと、サイトは一貫したドメイン名を使っていても、理解のないユーザーは、似ているだけの、あるいは似てもいないドメイン名の偽サイトを使ってしまうかもしれません。
だからといって、これらに意味がないとはされていないはずで。
HTTPSとドメイン名、最低限のこの2つのルールだけはどうにか覚えて、どうにか確認してウェブを利用してほしいと。
Re: (スコア:0)
「ブラウザ経由なら」という点に誤解がある
従来は偽ログインページをWebViewで表示させていたのを、偽Androidブラウザを作って表示させる仕様にされたら、たとえ「認証はブラウザから」というのが普及しても騙される可能性が高いから。
なにせ偽ブラウザだからURL表示はいくらでも誤魔化せるしね。
Re: (スコア:0)
アプリを偽造出来るところまで侵入されていたらどのみちアウトのような気が。
Re: (スコア:0)
このストーリー、もともとアプリからGoogleアカウントに紐付けるためのログインにWebViewを使うや否やという話だと思うけど？
Re: (スコア:0)
ブラウザでログイン済みならパスワードとIDの入力が不要だというところが味噌。ただしデフォルトのブラウザでグーグルのアカウントにログインしていないと意味がない。
ついでにパスワードとIDを盗みたい場合デフォルトのブラウザをユーザーに無断で変更する、偽のブラウザをインストールするなどという回りくどいことをする必要はないな。
ただ単にグーグルのログイン画面を模倣した偽の入力フォームをアプリ内で表示するか偽のログインページをブラウザで開けば済む話。
正直URLの偽装なんてしなくても大量に釣れるしURLを偽装したいならアプリ内でやればいい(アプリの切り替え風のアニメーションもつけとくとなお良い)。
Re: (スコア:0)
マジ迷惑です。
ユーザーにとっては、PokemonGOの認証がこの仕様になって、
会社のメールアカウントでログインしているつもりが
勝手に個人のメールボックスにはや代わりしていたりして、
混乱の元にしかなっていません。
Googleは勝手に個人IDと統合しようとする癖があるので、
管理者側も被害者にしかならないと思うので、やめてほしい。
Re: (スコア:0)
これを機会に業務用と個人用を分割してみては。
業務用途のみリモート接続にするとか。
Re: (スコア:0)
個人用のアカウントと仕事用のアカウントを分ければ済むだろ。
http://usedoor.jp/howto/digital/android-smartphone/android5-multi-acco... [usedoor.jp]
Re: (スコア:0)
>UIWebView/WKWebView on iOS,
androidだとは思ったのですが、iOSの可能性もあるのかなと思いまして。
PokemonGOやっていないので、双方の詳しい動作分からないんですよね。
Re: (スコア:0)
そのへんは過渡期なんでそのうちなれるでしょ。認証するときにどのアカウントで認証するか表示されません？
まあ会社のアカウントはメーラーだけに登録するのかいい。
Re: (スコア:0)
そもそもアドレスバーなくてそれが本物か確認できないもの(WebView)に認証情報入力なんてできませんわ〜
よっぽど名の知れた信頼できるアプリメーカーでもない限り。
まぁ世の中そんなもん気にせず使う人ばかりだもんなぁ。
よーわからんのだが (スコア:0)
アプリ内でWebView使うのは、トークンをアプリが受け取るためだと思ったが、
ブラウザで認証した場合、アプリはどうやってトークンを受け取ればいいの？
Re: (スコア:0)
intentでやれば？
Re: (スコア:0)
intentでやれば？
intentの挙動は所詮、OS依存の話であって、自分のアプリを意図したように呼んでくれるとは限りません
そしてアプリを配布する際にConsumer Keyを含んでいるんだから、悪意あるアプリが入ったら危険だからWebViewやめようね、って話題でintentは何の解決にもなりません
#という説明を理解できないならoAuthを使うアプリ作る資格ないと思う
Re: (スコア:0)
iPhoneもURLスキームでアプリ起動できるので、URLのパラメーターにトークンを付けておくだけですね。
違くて (スコア:0)
iOSならUIWebView/WKWebViewじゃなくSFSafariViewController、AndroidならWebViewじゃなくChrome Custome Tabsを使えとは言ってるけど、アプリ内でやるなとは言ってないよね。