おはようございます、ritouです。
GWも終わり、今日からまた仕事だー5月病だーなんて思っておられるところかと思います。
そんな皆様のやる気を減退させるような、後ろ向きなエントリを投げつけたいと思います。
今までいくつか関連するエントリを書いてきました。
この話はなかなか共感していただける方が少ないようです。
で、だんだん「あれ？私が変態なだけなのかな？」と思ってきました。
まぁ否定はできないところなのですが、今一度整理しておきたいと思います。
何の話か
次のようなサービスです。
- TVやPCなどで利用するサービス
- 認証はスマホでしたい
こんなことしたい理由としてはきっと
というところです。
で、こんなフローにたどり着くと。
手順を見ていきます。
手順１：TV/PCからスマートフォンのブラウザ/アプリへの誘導
手段はいくつかあるでしょう。
いずれもPINと表現している文字列などでTV/PCを利用しているユーザーにスマートフォンを利用させようとしています。
一般的なのはa)かもしれません。LINEのWindows向けデスクトップアプリではPC画面に表示されたQRコードをアプリから読ませます。
b)は、Youtube TVってのがユーザーにURL表示＋PIN入力を促しています。
知り合いのソーシャル隊長から教えていただいたのでYoutube TVってものを良く知らないのですが、まぁなんとなくTVで動きそうです。
手順２：スマートフォンで認証後の処理
アプリやブラウザでログインしていなかったらさせる部分は特に問題ありません。
その後、上に例を挙げたLINEのデスクトップアプリではユーザーがアプリ上で「ログイン」というボタンを押す、Youtube TVではユーザーがブラウザ上で許可をするとTV/PC側がログイン状態になります。
TV/PC上でユーザーに手を動かせるものは手順１のみであり、あとはバックエンドのWebサーバーからのPushを待つのか定期的に問い合わせるかなどで実現できそうです。
次に、このフローを利用した攻撃を考えます。
想定される攻撃：攻撃者による第3者のログインセッションののっとり
攻撃者側の流れとしては、
- 1. 攻撃者は自らのPC/TVから認証用URLを取得する
- 2. 第3者にそのURLを伝え、うまいこと言ってアクセスさせてTV/PCへのログインを許可させる
- 3. 後は待つ。うまくいけば目の前のTV/PCに第3者がログイン！！！
という感じでしょう。
攻撃者の気持ちになったとき、上記の実装に問題はないのでしょうか。
現状の実装における課題
手順１について、第3者にURLアクセスさせることは難しいことではないでしょう。
「アプリでこのURL読み込んで設定しておけば、普段使ってるPCで簡単にログインできるようになるよー」とか言っておけば数人は騙されそうです。
よく「怪しいURLをクリックしない」「HTTPS、ドメインを確認」なんていうフィッシング対策の啓蒙がされています。
しかし、ドメインやアプリは正常なもの、つまりLINEやYoutube(Google)なのでこれだけではすり抜けてしまう可能性があります。
a)のLINEのデスクトップアプリのURLは有効期限が5分のようです。これを短いととらえるか長いと捕らえるかは微妙なところでしょう。
ユーザーが操作などもたつく時間を考慮して長めにすれば攻撃者のチャンスも広がります。
あと、LINEアプリが必要という点ですが、天下のLINE様ですもの、世の中の人たちはけっこうな割合でアプリ入れてますよねーと。
b)のYoutube TVの場合はURL入力＋PIN入力なので難易度は上がるのかもしれませんが、なんとかできそうな気がします。
これを難しくするためにPINコード入力をさせてるのかとも考えましたが、正常なユーザーからしてもちょっとめんどくさい気がします。
手順２について、現状の実装では第3者が許可した瞬間に攻撃者のTV/PCがログイン状態になります。
ということは、許可する前に注意喚起を行うしかないでしょう。
現状の文言はこんな感じです。
- LINE : 「ログインしますか？」「PCにログインする場合、「ログイン」を押してください」なんか、とりあえずログインしちゃいそうです。
- Youtube TV : 「Youtube Leanbackが次の許可をリクエストしています・・・」事前設定だよとかいっておけば許可しそうですよね。
これでは心配です。
せめて「自分がTV/PCから利用しようとしている時以外は許可をしないでください。」と説明して理解してもらうことが必要だと思います。
ということで、実装のままリスクを下げる方法としては、
- 手順１のURLやPINの有効期限を（正常な使い方に影響を与えない範囲で）可能な限り短くする
- TV/PCでログイン状態にさせることを許可する画面の文言をわかりやすくする
というようなものがあるかと思います。
ハードウェア/ソフトウェアトークンと同様に1分とか30秒(+α)でExpireさせて切り替えるぐらいはできそうな気がします。
文言は詳しく書けば書くほど読んでもらえなくなりそうですしどうしましょう。
個人的には、これでは不十分で、もう一手間加える必要があると思っています。
より安全なしくみにするための提案
一言で言うと、「スマートフォンで認証した後に、ユーザーとPC/TV間のインタラクションを入れるべき」です。
これにより、許可したユーザーと実際にTV/PCを触っているユーザーが同じかどうかを確認したい。
攻撃者としても、URLをクリックさせたりPINを入力させることだけではなく、第３者からフィードバックをもらう必要があるとなるとハードルが上がるでしょう。
手段はいくつかあると思います。
- x) アプリやブラウザにPINコードを表示し、TV/PC側に入力させる
- y) TV/PC側に「認証完了」「続ける」ボタンを置き、アプリやブラウザで許可したあとにTV/PC側もクリックさせる
例えばビジネスホテルの有料チャンネル見たいときに廊下にある機械に1000円突っ込んで出てきたカードの数字を入力させたりします。
あれがx)のイメージですね。まぁ、あれは欲というか動機が強いから成り立っているのかもしれません。
TVもいろいろあるから、広く対応できる方法じゃないとダメって言われるだろうなとは予想してるのでy)も考えました。
自分の中では百歩譲った選択肢なのですが、タイミングをあわせる必要があるぶん、現状よりは良いかなと思ったりします。
まとめ
- TV/PC上のサービスにスマートフォンで認証させるフローが気になっている
- 現状の実装でリスクを下げる方法を考えた
- 一手間加えてさらにリスクを下げる方法を考えた
皆様はどう思われましたでしょうか？
攻撃者側にいわゆるソーシャルエンジニアリングが必要なため、なかなかこれをリスクと捕らえられていない問題だと思います。
以前の記事にも書きましたが、2009年4月に見つかったOAuth 1.0の脆弱性と解決法(1.0a)の内容と今回の件はとても似ています。
当時は実際の被害はなかったものの、こういう攻撃が行われる可能性があるというだけでOAuth 1.0のサービスプロバイダはOAuthの画面に警告文言を出すなどの大騒ぎとなりました。
Youtube TVについてはメールで問い合わせたところ、「お前の言ってるリスクは通常のフィッシングとかわらねぇなぁ。プロダクトの脆弱性とはいえないねぇ。」的な反応をされました。
「フィッシングとは違うじゃん。ドメインとか正しいし・・・」って返したのですが・・・私の英語が悪いせいかわかってもらえなかったみたいです。
今までは「こういうの使うのってリテラシー高いユーザーだから」とか言われたものですが、スマホシフトとか、O2OとかでスマホをハブにしたUXが増えてきたりするのかなーと思っています。
「LINEがやってるからうちも」とか言って似たような実装が広まってあとから問題が起こるのはよろしくないと思います。
ではまた。
