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

Tajima Itsuro @niryuu

@kokogiko 突然ですが、ソーシャルアプリの位置情報詐称対策で、プラットフォーム側にありうる脅威は、どういったものがあるんですか？

OHTSUKA Ko-hei @kokogiko

@niryuu プラットフォームと言うとOpenSocialプラットフォームの事ですか？それとも自前のサイトとかも含めて？

OHTSUKA Ko-hei @kokogiko

@niryuu 後者の前提で一般的な話をすると、結局ケータイでの位置取得はGET/POSTでの経緯度通知にすぎないので、ユーザが嘘情報を流し込むと詐称されてしまいます。なので、確実に自分達のリンクから来たと検証する手段か、GET/POSTの送付先を知られないための隠蔽手段が必要。

OHTSUKA Ko-hei @kokogiko

前者の場合、Cookieに1回限りの使い捨てセッション埋め込んだり、Refererをチェックしたりで防げます。最近はCookieやRefererに対応したケータイが主流になってきたので、古い（と言っても意外と最近までですが）DoCoMoケータイを無視するならこれが一番簡単かと。

OHTSUKA Ko-hei @kokogiko

CookieやReferer使えないDoCoMoケータイも相手にするなら、GETPOSTの送り先を徹底して隠蔽するしか方法はありません。と言っても、ガラケーはhtmlソースが見えないものが多いので、基本的には送られてきた位置情報をすぐリダイレクトしてしまえば、一時的には隠せます。

OHTSUKA Ko-hei @kokogiko

でも、一時的にはリダイレクトで隠せても、固定URLを通知先として使っていると、長期的にはバレます。ユーザにアクセス先URLを報告するキャリアのサービスもあり、また時にはケータイ網からPCでアクセスする攻撃者もいるので。なので、GET通知先URLはシグネチャ等で有効起源を設けます。

OHTSUKA Ko-hei @kokogiko

有効起源⇒有効期限ね。

OHTSUKA Ko-hei @kokogiko

大筋はこんな感じで、後は固有仕様への対応。DoCoMoのオープンiエリアは、DoCoMoサーバ上のページを経由するので、そこへのデータはPOSTで送ってそこから情報が漏れないようにするとか。

OHTSUKA Ko-hei @kokogiko

Willcomは位置情報通知先のURLをユーザに確認するけど、クエリストリングの中は表示しないので、Willcomで位置取得用URLの妥当性を検証するシグネチャはクエリストリングの中に含めるとか。（でもKDDIではクエリストリングを引き継げないので、URLに含めるしかない。）

OHTSUKA Ko-hei @kokogiko

DoCoMoのGPSは、住所録中のPOI情報や過去のGPS履歴から嘘のGPS情報を送れる機能がついているので、まずオープンiエリアで大体の位置を取得してから、GPSで得た位置との突き合わせで検証するとか。

Tajima Itsuro @niryuu

@kokogiko ありがとうございます。想定としてはOpenSocialです。例えばですが、会員制サービスをやっている会社が、付加価値として、既存のmixiアプリなどで提供しているソーシャルアプリを自社サービスに移植する場合、自前でOpenSocialを実装する必要があります。

OHTSUKA Ko-hei @kokogiko

@niryuu おはようございます。なんか後の喩え？がよく判りませんでしたが、OpenSocialを使う場合は、結局昨日述べたような勘所を自前で制御できないところにあります。

OHTSUKA Ko-hei @kokogiko

たとえば、まちつくの最初期にあった位置詐称脆弱性（？）は、最初はウノウ側で、URLでの位置受け取り後、リダイレクトしてなかったために通知URLがだだ漏れだったところにあります。

OHTSUKA Ko-hei @kokogiko

流石にこれはすぐにウノウは対処しましたが、次にオープンiエリアへの情報伝達でPOSTでなくGETを使っていたので、そこからURLが漏れて攻撃される危険があった。しかしそこはmixiプラットフォーム側の実装領域で、ウノウ側で対処／工夫のしようがないところでした。

OHTSUKA Ko-hei @kokogiko

私がブログで記事を書き、mixiにも送ったので、その問題も解決されました。が、もし通知URLが固定で検証のできないもののままであれば、長期的にはURLが漏れ、攻撃対象になる可能性がある。しかし、その脆弱性がまだ残っているのかどうかは、仕様がクローズドなので判断できません。

OHTSUKA Ko-hei @kokogiko

逆に言うと、仕様が開示されている人ならその固定URLを想定できてしまうので、もし通知URLがシグネチャ等を含まず検証不可能な固定値でもしあるならば、今もmixiプラットフォームには位置詐称脆弱性がある、という結論になります。

OHTSUKA Ko-hei @kokogiko

で、昨日からずっとせっかく話し始めたので、OpenSocialを使う場合の話だけでなく自前で実装する場合の話も続けようと思います。というか、OpenSocialでの安全性を判断する際にも、結局は自前で実装する際に考慮すべき点がプラットフォーム側で為されているか、が判断基準なので。

OHTSUKA Ko-hei @kokogiko

昨日はガラケーの、htmlソースが見られない前提での話をしましたが、WillcomやiPhone/Android等、JavaScriptが使える機種では、ブックマークレットでhtmlソースが見られてしまい、結果通知先のURLを知られてしまう危険があります。

OHTSUKA Ko-hei @kokogiko

こういう場合は、htmlソースの中では位置取得ロジックを書かずに、ユーザのインタラクションの後から位置取得ロジックを含んだJavaScriptを読み込んで、その中で位置取得処理をする必要があります。

OHTSUKA Ko-hei @kokogiko

位置取得処理＝具体的には、Willcomならhttp://location.request…へリダイレクト、iPhone/AndroidならGeoLocationAPIの実行です。もちろん、後読みJavaScriptファイル自体も、シグネチャやReferer/接続元IP検証必須。

OHTSUKA Ko-hei @kokogiko

iPhone/Androidは、GeoLocationAPI自体を悪意ある上書きができますが、これはAPI名の属性値を調べてやると、普通は「[native code]」が返るのに対し、上書きされてると「function(){}」が返ります。これをチェックすればOK。

OHTSUKA Ko-hei @kokogiko

ただし、検証できるのはJavaScrptレベルでの上書きのみで、iPhoneのJailBreak等でライブラリから置き換えられちゃうと、これでは検証不可能。

OHTSUKA Ko-hei @kokogiko

JailBreakでの詐称の検証は完璧は絶対無理だけど、大体そういう場合の嘘位置送信手段は、人間系で入力させるか、一定値を自動で送り続けるかなので、その辺を逆手に取った簡易対策は可能。

OHTSUKA Ko-hei @kokogiko

つまり、位置を一回ではなく数回取得してやり、その反応時間や揺らぎを見る事で、人間系でいちいち入力してるから時間掛かってるな、とか、自動で送信してるから全然揺らがないな、とか検証するやり方。

OHTSUKA Ko-hei @kokogiko

JavaScriptでhtmlソースが見られるのはWillcomやiPhone/Androidは確実だけど、DoCoMoやSoftBankのJavaScript対応端末でhtmlソースが見られるかは私も確認していない。よって対策も不明だけど、同じ発想で対応できるのでは？と思う。