パスワードを忘れた? アカウント作成
12899779 story
Google

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を使うのはやめよう)。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2016年08月31日 8時24分 (#3072829)

    まず「WebViewからの認証がブロックされた」ことを開発者でなくユーザーが理解しないとほとんど意味がない
    たとえば悪意あるアプリがWebView経由でGoogleログインに偽装した画面を表示し、GoogleのIDとパスワードを剽窃する行為を防ぐには「WebViewとはどんな画面か」「そこにGoogleのID等をいれてはいけない」という事情をユーザー側が理解しないと結局防げないだろう
    真っ当なアプリがWebViewを使わない仕様に変わったところで、それがどういう事情に根ざしてるかユーザーが理解しないでいれば、結局はID剽窃目的のアプリのカモにされうる、というリスクは殆ど変わらないわけだ
    # この辺はTwitterのクライアントアプリがBASIC認証が禁止されてoAuthになったときの状況にかなり似てると思う

    更に言うならブラウザから認証させるにしても「偽のブラウザ画面」を用意されたら割と騙されるよね
    まあ偽のブラウザ画面を用意させる手間の分だけマルウェアが作りにくくなると思うけど、それはどこまで効果があるのか……

    と、考えるとそもそも認証基盤そのものを抜本的に変更しない限り、この問題はいつまでも続くと思うなぁ

    • by Y-taro (38255) on 2016年08月31日 9時17分 (#3072852)

      地道に習慣を根付かせていくんじゃないですかね。
      わかりやすいルールであれば、より根付きやすい。
      ブラウザ経由であれば、一般的なブラウザ利用上の理解が通用するわけで、別途ルールを覚える必要がない。

      サイト側が実施する従来からのセキュリティ上の配慮にしたって、必ずしもユーザーに広く理解されているとは限りませんよね。

      中間者攻撃でログインフォームが改竄される可能性があるからと、サイトはログインフォームの段階からHTTPSで用意していても、理解のないユーザーは、HTTPアクセス時に改竄で挿入された偽ログインフォームを使ってしまうかもしれません。
      偽サイトによるフィッシングが判別しやすいようにと、サイトは一貫したドメイン名を使っていても、理解のないユーザーは、似ているだけの、あるいは似てもいないドメイン名の偽サイトを使ってしまうかもしれません。

      だからといって、これらに意味がないとはされていないはずで。
      HTTPSとドメイン名、最低限のこの2つのルールだけはどうにか覚えて、どうにか確認してウェブを利用してほしいと。

      親コメント
      • by Anonymous Coward

        「ブラウザ経由なら」という点に誤解がある

        従来は偽ログインページをWebViewで表示させていたのを、偽Androidブラウザを作って表示させる仕様にされたら、たとえ「認証はブラウザから」というのが普及しても騙される可能性が高いから。
        なにせ偽ブラウザだからURL表示はいくらでも誤魔化せるしね。

        • by Anonymous Coward

          アプリを偽造出来るところまで侵入されていたらどのみちアウトのような気が。

          • by Anonymous Coward

            このストーリー、もともとアプリからGoogleアカウントに紐付けるためのログインにWebViewを使うや否やという話だと思うけど?

        • by Anonymous Coward

          ブラウザでログイン済みならパスワードとIDの入力が不要だというところが味噌。ただしデフォルトのブラウザでグーグルのアカウントにログインしていないと意味がない。
          ついでにパスワードとIDを盗みたい場合デフォルトのブラウザをユーザーに無断で変更する、偽のブラウザをインストールするなどという回りくどいことをする必要はないな。
          ただ単にグーグルのログイン画面を模倣した偽の入力フォームをアプリ内で表示するか偽のログインページをブラウザで開けば済む話。
          正直URLの偽装なんてしなくても大量に釣れるしURLを偽装したいならアプリ内でやればいい(アプリの切り替え風のアニメーションもつけとくとなお良い)。

      • by Anonymous Coward

        マジ迷惑です。

        ユーザーにとっては、PokemonGOの認証がこの仕様になって、
        会社のメールアカウントでログインしているつもりが
        勝手に個人のメールボックスにはや代わりしていたりして、
        混乱の元にしかなっていません。

        Googleは勝手に個人IDと統合しようとする癖があるので、
        管理者側も被害者にしかならないと思うので、やめてほしい。

        • by Anonymous Coward

          これを機会に業務用と個人用を分割してみては。
          業務用途のみリモート接続にするとか。

        • by Anonymous Coward

          そのへんは過渡期なんでそのうちなれるでしょ。認証するときにどのアカウントで認証するか表示されません?
          まあ会社のアカウントはメーラーだけに登録するのかいい。

    • by Anonymous Coward

      そもそもアドレスバーなくてそれが本物か確認できないもの(WebView)に認証情報入力なんてできませんわ〜
      よっぽど名の知れた信頼できるアプリメーカーでもない限り。

      まぁ世の中そんなもん気にせず使う人ばかりだもんなぁ。

  • by Anonymous Coward on 2016年08月31日 11時38分 (#3072930)

    アプリ内でWebView使うのは、トークンをアプリが受け取るためだと思ったが、
    ブラウザで認証した場合、アプリはどうやってトークンを受け取ればいいの?

    • by Anonymous Coward

      intentでやれば?

      • by Anonymous Coward

        intentでやれば?

        intentの挙動は所詮、OS依存の話であって、自分のアプリを意図したように呼んでくれるとは限りません
        そしてアプリを配布する際にConsumer Keyを含んでいるんだから、悪意あるアプリが入ったら危険だからWebViewやめようね、って話題でintentは何の解決にもなりません

        #という説明を理解できないならoAuthを使うアプリ作る資格ないと思う

    • by Anonymous Coward

      iPhoneもURLスキームでアプリ起動できるので、URLのパラメーターにトークンを付けておくだけですね。

  • by Anonymous Coward on 2016年08月31日 13時15分 (#3072992)

    iOSならUIWebView/WKWebViewじゃなくSFSafariViewController、AndroidならWebViewじゃなくChrome Custome Tabsを使えとは言ってるけど、アプリ内でやるなとは言ってないよね。

typodupeerror

にわかな奴ほど語りたがる -- あるハッカー

読み込み中...