2010年6月10日

位置ゲーの位置詐称対策で検討すべき事

位置ゲー系の詐称対策で知っている事をまとめてみました。
携帯 位置ゲー
kokogiko 21205view 8コメント
45
ログインして広告を非表示にする
  • Tajima Itsuro @niryuu 2010-06-09 22:33:44
    @kokogiko 突然ですが、ソーシャルアプリの位置情報詐称対策で、プラットフォーム側にありうる脅威は、どういったものがあるんですか?
  • OHTSUKA Ko-hei @kokogiko 2010-06-09 23:43:08
    @niryuu プラットフォームと言うとOpenSocialプラットフォームの事ですか?それとも自前のサイトとかも含めて?
  • OHTSUKA Ko-hei @kokogiko 2010-06-09 23:49:30
    @niryuu 後者の前提で一般的な話をすると、結局ケータイでの位置取得はGET/POSTでの経緯度通知にすぎないので、ユーザが嘘情報を流し込むと詐称されてしまいます。なので、確実に自分達のリンクから来たと検証する手段か、GET/POSTの送付先を知られないための隠蔽手段が必要。
  • OHTSUKA Ko-hei @kokogiko 2010-06-09 23:52:27
    前者の場合、Cookieに1回限りの使い捨てセッション埋め込んだり、Refererをチェックしたりで防げます。最近はCookieやRefererに対応したケータイが主流になってきたので、古い(と言っても意外と最近までですが)DoCoMoケータイを無視するならこれが一番簡単かと。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 00:09:05
    CookieやReferer使えないDoCoMoケータイも相手にするなら、GETPOSTの送り先を徹底して隠蔽するしか方法はありません。と言っても、ガラケーはhtmlソースが見えないものが多いので、基本的には送られてきた位置情報をすぐリダイレクトしてしまえば、一時的には隠せます。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 00:14:04
    でも、一時的にはリダイレクトで隠せても、固定URLを通知先として使っていると、長期的にはバレます。ユーザにアクセス先URLを報告するキャリアのサービスもあり、また時にはケータイ網からPCでアクセスする攻撃者もいるので。なので、GET通知先URLはシグネチャ等で有効起源を設けます。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 00:19:25
    大筋はこんな感じで、後は固有仕様への対応。DoCoMoのオープンiエリアは、DoCoMoサーバ上のページを経由するので、そこへのデータはPOSTで送ってそこから情報が漏れないようにするとか。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 00:22:23
    Willcomは位置情報通知先のURLをユーザに確認するけど、クエリストリングの中は表示しないので、Willcomで位置取得用URLの妥当性を検証するシグネチャはクエリストリングの中に含めるとか。(でもKDDIではクエリストリングを引き継げないので、URLに含めるしかない。)
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 00:26:37
    DoCoMoのGPSは、住所録中のPOI情報や過去のGPS履歴から嘘のGPS情報を送れる機能がついているので、まずオープンiエリアで大体の位置を取得してから、GPSで得た位置との突き合わせで検証するとか。
  • Tajima Itsuro @niryuu 2010-06-10 00:12:09
    @kokogiko ありがとうございます。想定としてはOpenSocialです。例えばですが、会員制サービスをやっている会社が、付加価値として、既存のmixiアプリなどで提供しているソーシャルアプリを自社サービスに移植する場合、自前でOpenSocialを実装する必要があります。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 06:25:07
    @niryuu おはようございます。なんか後の喩え?がよく判りませんでしたが、OpenSocialを使う場合は、結局昨日述べたような勘所を自前で制御できないところにあります。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 06:28:18
    たとえば、まちつくの最初期にあった位置詐称脆弱性(?)は、最初はウノウ側で、URLでの位置受け取り後、リダイレクトしてなかったために通知URLがだだ漏れだったところにあります。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 06:30:58
    流石にこれはすぐにウノウは対処しましたが、次にオープンiエリアへの情報伝達でPOSTでなくGETを使っていたので、そこからURLが漏れて攻撃される危険があった。しかしそこはmixiプラットフォーム側の実装領域で、ウノウ側で対処/工夫のしようがないところでした。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 06:34:10
    私がブログで記事を書き、mixiにも送ったので、その問題も解決されました。が、もし通知URLが固定で検証のできないもののままであれば、長期的にはURLが漏れ、攻撃対象になる可能性がある。しかし、その脆弱性がまだ残っているのかどうかは、仕様がクローズドなので判断できません。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 06:39:40
    逆に言うと、仕様が開示されている人ならその固定URLを想定できてしまうので、もし通知URLがシグネチャ等を含まず検証不可能な固定値でもしあるならば、今もmixiプラットフォームには位置詐称脆弱性がある、という結論になります。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 06:45:29
    で、昨日からずっとせっかく話し始めたので、OpenSocialを使う場合の話だけでなく自前で実装する場合の話も続けようと思います。というか、OpenSocialでの安全性を判断する際にも、結局は自前で実装する際に考慮すべき点がプラットフォーム側で為されているか、が判断基準なので。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 07:12:45
    昨日はガラケーの、htmlソースが見られない前提での話をしましたが、WillcomやiPhone/Android等、JavaScriptが使える機種では、ブックマークレットでhtmlソースが見られてしまい、結果通知先のURLを知られてしまう危険があります。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 07:16:21
    こういう場合は、htmlソースの中では位置取得ロジックを書かずに、ユーザのインタラクションの後から位置取得ロジックを含んだJavaScriptを読み込んで、その中で位置取得処理をする必要があります。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 07:18:32
    位置取得処理=具体的には、Willcomならhttp://location.request…へリダイレクト、iPhone/AndroidならGeoLocationAPIの実行です。もちろん、後読みJavaScriptファイル自体も、シグネチャやReferer/接続元IP検証必須。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 07:22:54
    iPhone/Androidは、GeoLocationAPI自体を悪意ある上書きができますが、これはAPI名の属性値を調べてやると、普通は「[native code]」が返るのに対し、上書きされてると「function(){}」が返ります。これをチェックすればOK。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 07:24:07
    ただし、検証できるのはJavaScrptレベルでの上書きのみで、iPhoneのJailBreak等でライブラリから置き換えられちゃうと、これでは検証不可能。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 07:26:52
    JailBreakでの詐称の検証は完璧は絶対無理だけど、大体そういう場合の嘘位置送信手段は、人間系で入力させるか、一定値を自動で送り続けるかなので、その辺を逆手に取った簡易対策は可能。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 07:28:13
    つまり、位置を一回ではなく数回取得してやり、その反応時間や揺らぎを見る事で、人間系でいちいち入力してるから時間掛かってるな、とか、自動で送信してるから全然揺らがないな、とか検証するやり方。
  • OHTSUKA Ko-hei @kokogiko 2010-06-10 07:33:10
    JavaScriptでhtmlソースが見られるのはWillcomやiPhone/Androidは確実だけど、DoCoMoやSoftBankのJavaScript対応端末でhtmlソースが見られるかは私も確認していない。よって対策も不明だけど、同じ発想で対応できるのでは?と思う。

コメント

  • OHTSUKA Ko-hei @kokogiko 2010-06-11 17:31:34
    コロプラプラットフォームの話も追記してみました。 これからやるのならば、自前開発よりもプラットフォームに乗っかった方がよいのではないかと。
  • OHTSUKA Ko-hei @kokogiko 2010-06-11 17:34:08
    もっとも何時出るか判らないので、既に企画があれば仕方がないですが、それでも難しいスマホは無視して3キャリだけのミニマムスタートにし、何時でも乗り換えられるようにしてスマホはコロプラプラットフォーム利用後に対応、というのが賢いかも。
  • Tajima Itsuro @niryuu 2010-06-11 18:11:31
    コロプラプラットフォーム、よくわかんないけどOpenSocial勢はOpenSocialが提供する位置情報APIとバッティングして難しそう
  • OHTSUKA Ko-hei @kokogiko 2010-06-13 11:08:57
    @niryuu そうなんですよ。なので、正直なところをいうと本当は今回コロプラが出すような位置ゲープラットフォーム機能はOpenSocial勢に実装して欲しかったし、個人的にはその辺のノウハウ手みやげに今回OpenSocial勢の会社も軒並み求職しましたが見事に (ry
  • Tajima Itsuro @niryuu 2010-06-15 02:31:47
    ともかく、この記事の件に関しては全面的に私が悪かったと感じております。関係各所におかれましては、まことに申し訳ございません。
  • デル(−x−)←クール @delecour 2011-01-18 22:37:22
    RT @kokogiko: [B!] おおお?コロプラの位置ゲープラットフォーム化公式発表出てたのか。スバラシス。 http://bit.ly/9FUtze コロプラ、位置情報を軸にしたプラットフォーム事業展開へ - ケータイ Watch
  • デル(−x−)←クール @delecour 2011-01-18 22:37:50
    RT @kokogiko: コロプラの発表知らなかったんで、昨日位置詐称技術ガーッと書いちゃったけど、正直位置ゲーで自社でその辺ノウハウ作るのは検証環境作るだけでも大変だし、よほどの理由(コロプラ嫌いとか?w)がなければコロプラの出てくるであろうプラットフォームに乗るのが無難。
  • デル(−x−)←クール @delecour 2011-01-18 22:38:55
    RT @kokogiko: よく使う喩え。家でゴロゴロしてる一時間にドラクエ遊んで、新幹線に乗ってる一時間にFF遊んで、両者に質の差はあるか?と言えばそんなもの存在しない。しかし位置ゲーでは存在する。新幹線に乗ってる方の限られた一時間に遊んでもらえるゲームとしてユーザに選んでもらえないと、生き残れない。

カテゴリーからまとめを探す

「大喜利」に関連するカテゴリー