Last active
September 29, 2016 02:32
-
-
Save mala/8112696 to your computer and use it in GitHub Desktop.
Revisions
-
mala revised this gist
Dec 24, 2013 . 1 changed file with 3 additions and 3 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -487,7 +487,7 @@ LINE, NAVER, Google, etc ---- <img src="https://dl.dropboxusercontent.com/u/4195329/seccon2013/sparrow_ios_screenshot.PNG"> ---- @@ -535,7 +535,7 @@ LINE, NAVER, Google, etc ---- <img src="https://dl.dropboxusercontent.com/u/4195329/seccon2013/mailbox_blog.png"> ---- @@ -644,7 +644,7 @@ JS実行出来るだけで危険だったらブラウザが危険 Mailboxの場合 <img src="https://dl.dropboxusercontent.com/u/4195329/seccon2013/mailbox.png"> ---- -
Dec 24, 2013 . 1 changed file with 0 additions and 1 deletion.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -1,4 +1,3 @@ スマートフォンのセキュリティについて ma.la -
Dec 24, 2013 .There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -0,0 +1,1150 @@ スマートフォンのセキュリティについて ma.la ---- ### 自己紹介 http://ma.la https://twitter.com/bulkneets ---- LINE株式会社 livedoor方面の人です ---- ## 仕事 - JavaScript, Perl - 元々の専門領域はUI, フロントエンド - Webアプリ全般 - 認証認可周り ---- ## セキュリティに関する業務 - 自社サービスのリリース前にチェックしたりとか - 何か新しい攻撃手法見つかったら調査 - 他社サービスの問題見つけて報告したり - オープンソースプロダクトのバグ報告したり ---- そもそも何でJavaScriptを書いてた人間が セキュリティに関することをやっているのか ---- - あらゆるデバイスでHTML + JavaScriptが使われている - どこまで悪用できるのか、どうやって修正すべきなのか - 社内でもっとも詳しい ---- - 基本的にはWebの人 - iOS / Android アプリ開発あまり詳しくない - セキュリティチェックやる関係で覚えている ---- ## 自社サービス - livedoor, NAVERのWebサービス - 最近はLINEに関するあれこれも -- - サービスリリース前にやること - QA / セキュリティQA - 社内ベータリリース -- - リリース前のレビュー - 機械的な検査で見つからないような問題を見つける - ポリシー制定や事故が起きた時の相談に乗ったり ---- ## 脆弱性報告のハンドリング - 個人的に報告を受けたものの調整 - 担当者に伝える or 自分で直す - livedoorのものは大体直せる - 修正方法の指示から修正完了の確認まで。 -- - 一個見つけたら複数ある - 一つの脆弱性について全サービス網羅的に調査 ---- ## 他社サービスの事例 - Google, Facebook, Twitter, Yahoo, Amazon, Evernote, etc - hatena, mixi, Doorkeeper, 任天堂, etc - 表立って書いたりするのはXSSが多い - 個人の活動です。 - たまたま業務時間中に見つけることもありますが個人の活動です ---- ## なぜ他社サービスのバグ報告をするか - 単に自分の使ってるサービスが安全か気になる -- - 自社で見つけた問題は他社にもある - 他社で見つけた問題が自社にもある - 持ちつ持たれつ ---- なんかXSSばっかり探してるみたいに思われたりすることがあるのですが もっとクリティカルなバグとか色々報告してたりします ---- - 公開しているのは公開しても良さそうなもの - 公開しているものより遥かに多く報告している - アプリの脆弱性 → バージョンアップが浸透するまで話しにくいことがある ---- ## 今日話すこと - スマホアプリ、モバイルアプリケーションにおけるセキュリティ ---- LINEの話じゃないですよ！ 一般論です ---- ### スマホアプリ - Webベースの技術が多く使われている - 今までブラウザ上で起きていたようなことがスマホアプリ内で起きている ---- ### スマホアプリにおけるセキュリティ - 個人的に色々と発見してきた経験から - 発見手法や修正方法について - 安全なアプリを作るためにはどうすればいいのか？ ---- ## スマホの話の前に - 通常のWebアプリケーションでの事例をざっくりと ---- ## Webアプリにおけるセキュリティ動向 ---- ## XSS クロスサイトスクリプティング 説明必要？ ---- - 自動エスケープしてれば大体大丈夫です - テンプレートエンジン側で安全側のポリシー - それでカバー出来ていない事例に気を使えば良い ---- ## JavaScriptの動的生成 - scriptタグ内やonclick属性内にテンプレート変数を埋めこんでいるケース - 安全にするのが非常に難しいのでやらないで! ---- ## javascript: へのリンク - a hrefへの指定 → クリック時にscript実行 - iframe srcへの指定 → ロード時にscript実行 - img srcほか → 昔は実行されたが今は実行されない ---- - ここらへんは普通のXSS - 世の中にはまだまだたくさん - 自社サービスではあまり見かけなくなりました ---- ## DOM based XSS - jQueryを使っているケース - 外部ドメインをXHRで読み込めてしまうケース ---- ## jQuery Mobileの悪夢 - 複数のXSS脆弱性の存在 - 旧バージョン使ってるサイトほぼ全部XSS可能 - 公式サイトの利用事例から飛べるページほぼ全部 ---- ## 原因と対策 - location.hashに指定されたパスを読み込んでHTMLの部分書き換え - jQuery Mobileの基本機能 - 任意のURLをロード可能になっていた → 表示中のドメインの権限で評価される ---- ## 対策は - 読みこむ前に現在表示中のドメインと一致するかどうか検査するように - 未だに潜在的な問題はある - 「同一ドメイン」のリソースはHTMLとして読み込んでも安全だ、という暗黙の前提 ---- - HTMLじゃないものがHTMLとして評価される問題 - 以前は IE限定の問題として存在 - X-Content-Type-Options: nosniff ---- ### JSでの動的ロードとの組み合わせ - テキストファイル - 画像(のコメント部分にHTML) - JSON、CSV etc - HTMLじゃないものがHTMLとして評価される - リダイレクタなどが絡むと話がややこしくなります ---- ## Ruby on Rails の Turbolinks - Ajax + history.pushState で高速に画面切り替え - githubでやってるようなやつ -- - jQuery Mobileと同様の問題 - ユーザーがサイト内の任意のURLにリンクを貼れるようなケース - やや特殊だが十分に有り得る(潜在的XSS) - 対応: htmlのみ受け入れ、リダイレクトを拒否 - Rails プチコミッター ---- ## AngularJS - 最近アツいと話題の - 振る舞いを記述していい感じにMVCしてくれるやつ - https://code.google.com/p/mustache-security/wiki/AngularJS - ユーザーがclass名を自由に書けるようなケース？？？ - 流石になさそうだけど今後問題になるかも - むしろ Content Security Policy bypass としてのリスク ---- ### リッチテキストエディタ上でのXSS - リッチテキストエディタのiframe内でのXSS - TinyMCEや、その派生プロダクト - 最近多数報告 ---- ## 自社サービスでの事例 - livedoor Blog - NAVERのサービス ---- ## 他社サービスでの事例 - wordpress.com XSS 修正済み - Movable Type XSS 修正済み - ほかにも調整中のいくつか ---- ### HTMLパーサの挙動の違いによるXSS - 解釈にブレが生じるようなHTMLを入力する - サーバー側やJSのフィルタをすり抜ける。 - 禁止されてるはずのタグが通る! ---- ## Flash based XSS - 普通のXSSは見つかりにくくなっている - Flash based XSSがアツい! - 事例についてまとめてます - http://subtech.g.hatena.ne.jp/mala/20130604/1370328779 ---- ### Flash based XSSの原因 - ExternalInterface.call - htmlText によるタグ出力 - 外部swfのロード ---- ### Flashのセキュアコーディング? - 今さらどうしようもない - 今からFlash書く人はあまりいない - 必要とされてるケースで適切なライブラリを使う - メンテされてるライブラリかどうかの選定が大事 ---- ## 著名どころ - swfupload - zeroclipboard - 動画プレイヤーあれこれ ---- ## 動画プレイヤーのXSS - videoタグのfallbackとしてFlash - まだ必要とされる状況 ---- ## 動画プレイヤーのXSS - ぶっちゃけ全部ダメだった - あれもこれも全部XSSがある - JWPlayer, Video-js, mediaelement, flowplayer, etc - 古いバージョン使った覚えがあるなら更新を。 ---- ## 自社サイトでの事例 - すごくたくさん - ブログに書いてから気付いたものもあり ---- ## 他社サイトでの事例 - IPA脆弱性報告窓口に届出 - 調整中 ---- ### なんでこんなことになってるの？ - Flash側でのイベントをJavaScriptに通知 - 呼ばれる関数をカスタマイズ出来るようになっているものが多い - some_swf?debug=function(){alert(/XSS/)} - そもそもFlash → JSへの引数受け渡しの際の処理がバグってたりする ---- ## Flashの問題 - Player側で直すべきバグが直らない - 時として互換性のために不適切な仕様のまま放置 - 多くのswfが古いバージョンのママ放置されている ---- ## Webの話 - だいたいこんな感じ ---- ## Web → スマホ - 脆弱性の発生しやすいポイントは同じ - WebView + XSS - CSRFに似たもの(Cross-Application request forgeries) - 他言語とのブリッジ機能 ---- ## スマホアプリといっても色々 - Webベースのもの - HTML5ベースのもの - プラットフォーム固有のUIコンポーネント使うもの ---- ## Webベースのアプリ - スマホ向けのWebサイト - あるいはそれを表示するだけのアプリ ---- ## ネイティブ寄りのアプリ - ローカルのHTML5 + JSで作られているもの - プラットフォームネイティブのUIコンポーネントで作られているもの - いずれにせよ内部ではhttp/https使ってることが殆ど ---- ## スマホアプリとは - 結局のところ特定サービス向けの専用ブラウザ - であることが非常に多い - Webの技術、ノウハウが流用できる - HTML/JSを調査することで脆弱性を見つけられる - Webで起きてることはスマホアプリ上でも起きる ---- # 調査方法の話 ---- ### 調べ方 - 通信をキャプチャして調べる - アプリケーションの保存しているデータを調べる - ソースコードから調べる(自社アプリ) - リバースエンジニアリング(Android) ---- ## 通信の解析 - 最近はもっぱらmitmproxyというのを使ってます ---- ## mitmproxy - http://mitmproxy.org - pythonで書かれたproxyサーバー - 端末にルート証明書を入れてHTTPSの通信をキャプチャ ---- ## mitmproxy - WiFi立てるの面倒なのでVPN経由で使えるようにしてある - VPN有効に → 80,443の全ての通信をmitmproxyの透過プロキシ経由に。 - iOSでもAndroidでもVPNの設定はあまり難しくない ---- ### Why VPN - 社内で開発用にWiFiアクセスポイント作る人多すぎ - 干渉して無線つながりにくくなる - 野良WiFi禁止令が出た ---- ### 通信をキャプチャして分かること - 内部で叩いているAPI → これ直接アクセスしたらどうなるんだろ？ - 平文通信 → 改竄された場合の影響はどの程度？ - アクセス解析やトラッキングで送られているデータ ---- ### 保存しているデータを調べる - 端末とUSBケーブルで接続してマウント - 保存されているファイルを調べたり書き換えたり - ディレクトリ構成を調べる → 個人情報が保存されてそうなファイルを見つける - アプリ内の脆弱性でファイルが読めないか調べる ---- ## ソースコードから調べる - apkの逆コンパイル - 自社アプリのソースコードから - 最も効率がよく網羅的に調べられる ---- ### 調査方法 - 大体こんな感じ ---- ## 脆弱性のあったアプリの事例 - 自分が発見報告してきたもの ---- ## ケーススタディ ### WebViewに関するもの ---- Sparrow, Mailbox, Boxcar, LINE, NAVER, Google, etc ---- ## メールアプリでのXSS - HTMLメール表示機能でscript実行可能な事例が多数 - Sparrow - Mailbox ---- ## Sparrow - 評判の良いメールクライアント - Googleに買収された - その少し前にちょうどバグ報告していた ---- <img src="sparrow_ios_screenshot.PNG"> ---- ## Sparrowのケース - とあるサービスの名前の設定にHTMLタグを入れていた - お知らせメールの件名部分でタグが有効になっていた - 怪しいと思って検証 - ブラックリストでの制限だった -- - audioやvideo用の新しいイベントハンドラ - 既存のブラックリストに書いてない → 通る - OSXで問題があったのでiOSバージョンも調べる - 同様にメール表示画面でJavaScript実行可能だった ---- ### 何が出来たのか？ - JavaScriptからメール本文の入っているsqliteファイルにアクセス可能だった - 受信した全てのメールを盗み取ることが可能 - iOS5ではアドレス帳のデータベースファイルの読み取りも可能 ---- ### 何故こうなるのか？ - 権限の強いUIWebViewでメールを表示している - BaseURLが無指定 or file:// - そのアプリのDocumentにアクセス可能になる ---- ## Mailboxの事例 - Dropboxに買収された - Gmail用クライアント、OAuth使ってサーバーサイドで受信している - Mailboxのサーバー側でタグをフィルタ可能 - 海外で問題を指摘されてサーバー側でのフィルタで対応していた ---- ## Mailboxの事例 - 2013年9月 - HTMLメール内でのJavaScript実行の問題が指摘される - http://miki.it/blog/2013/9/24/mailboxapp-javascript-execution/ ---- <img src="mailbox_blog.png"> ---- "As many have noted, the real risks presented by running javascript within Mailbox are extremely limited thanks to how iOS is designed." 多くの人が指摘してるようにMailbox上でのjavascript実行によるリスクは極めて限定的です、iOSの設計に感謝 ---- "extremely limited" "thanks to how iOS is designed." ---- お前は何を言っているんだ ---- ## おいイタリアのブロガー - 動画とって長文書いてる暇あったら alert(location) を書け - 影響範囲を適切に把握することが必要 ---- - バグ報告に動画はいらない - Google: デモ動画より短い実証コード -- ## Mailboxの対応 - 公式ブログで「sandboxによって影響は極小」とアナウンス - 正直この段階では、分からない - 「あ、こいつ分かってなさそう」→ 調べる ---- ## Mailboxの事例 - 元の報告者: 抜けがあって再度修正、という記事 - まだまだ抜け穴あるんじゃないの？ - → ここでHTMLパーサの挙動の違いによるXSS ---- ## Mailboxの事例 - 変なタグたくさん作って試す - 普通のメーラーでは送れないことが多い - HTMLメール送信script書く or メーラの送信待ちファイルをエディタで編集 ---- ## こういうのです ``` <!--> < script> your code here < /script> --> ``` ---- ``` <!--> < script> your code here < /script> --> ``` - HTMLパーサライブラリの多くはコメントとして解釈 - 実際のブラウザでは一行目でコメント終了と見なす - 知らないと気付かない ---- ## パーサの挙動の違いによるXSS - ブラックリストは危険です - パースして、正規化したHTMLを再構成すること ---- ## UIWebView + XSS - SparrowもMailboxもUIWebView内でJavaScriptが実行できた - 実際のところどこまで出来たのか？ - セキュリティ研究者もリスクを正しく認識出来ていない - 元の報告者は「Jailbreakされてるデバイスで危険」と主張 ---- ## Jailbreakしてると危険? - iOS関係でよく聞くフレーズ。 - Jailbreakはマジで関係ないです - WebKitのバグをついたら危険 → それはWebKitのバグです ---- ## 正しい答え - BaseURLによる - UIWebViewのBaseURLです ---- JS実行出来るだけで危険だったらブラウザが危険 どういう権限、コンテキストで動いてるのかが重要 ---- Mailboxの場合 <img src="mailbox.png"> ---- file:// で動いてる!! なんかまずそう ---- ## PoCを作る 1. データを保存してるパスを調べる(iPhone Explorer等) 2. JSからファイル読み取るコードを書く 3. ファイルサイズ取れれば成功 4. リモートにデータ送るコードを書く ---- ## 実際の脅威は？ - SparrowもMailboxも強い権限のWebViewで動作。 - 「受信済みメールを全て盗み出せることが出来る脆弱性」だった ---- ## その後 - Mailbox Appの問題は修正された - そもそも「WebViewの権限を制限したほうが良い」とアドバイス - 「ブログ記事を訂正したほうが良い」ともアドバイス -- Dropboxの容量増えた 10GB -- 今時10GB? と文句言ったら 100GB 増えた ---- ## 自社での事例 - スマホアプリ中でのXSS - 自分のブログで解説記事を書く - しかし自社やグループ会社のアプリで同等の問題 - 同じ説明を繰り返す日々 - oh.. ---- ## 共通して言えること - 強い権限を持つWebViewでのJavaScript実行 - 開発元: sandboxで制限されると主張 - 実際は: メールのデータベース全部読める、iOSのアドレス帳読める - 開発者がリスクを正しく認識できていない ---- ### 脆弱性見つけたら - どこまで悪用できるか調べることまでセット - "JavaScriptが実行できるバグ" なのか "個人情報を盗み出せる脆弱性" なのか -- - 最初は自分も「そんなことできんの？？」だった - プラットフォーム毎にリスクは異なる - そのプラットフォーム上のバリバリ現役開発者じゃないと分からない - そういう人がセキュリティに興味ないと → 情報出まわらない - laisoさんというひとが調べてくれた - http://d.hatena.ne.jp/laiso+iphone/20111003/1317651353 ---- ## iOSのアドレス帳のパーミッション - addressbook.sqlitedb - iOS5: file:// からであれば許可無く読み込めた - iOS6: アプリが一度アドレス帳を読み込んだ後なら読み込めた - iOS7: file:// で直接アクセスが不可能になった ---- ## アドレス帳直読み問題 - UIWebView上のJavaScriptからローカルファイルが読める - そのアプリのドキュメントならOK - OSのアドレス帳のsqliteファイル読める意味がどこに？ - アップルに問い合せてみたり。 -- - 俺「なんでJavaScriptからアドレス張読めちゃうの？」 - ア「それはアプリ側の問題です、こちらのセキュアコーディングに関する講演動画を・・・」 -- - 俺「iOS7 betaでは直ってるみたいなんだけど」 - ア「iOS7 ではSandboxの強化が行われて・・・」 -- - 完全な修正はiOS7以降 ---- ## 大事なこと - Sandboxが何を保護するものなのか理解すること - アプリケーションごとのプロセスの分離 - iOSの設計に感謝する前に調べましょう ---- ## Sandboxの目的は - 「別プロセス」から干渉できなくすること - 自分自身の保持しているデータは多くの場合、当然に読める ---- ## on Android ---- ## Androidにやや固有の問題 - addJavascriptInterfaceの問題 - WebViewを使っているアプリの非常に多くが影響を受ける - 参考: http://ierae.co.jp/uploads/webview.pdf ---- ## addJavascriptInterfaceの問題とは - JavaScriptからアプリ側の関数を呼び出すためのブリッジ - 本来開発者の指定したメソッドしか呼び出せないとおもいきや - Javaのリフレクションを使って任意のメソッド呼び出し可能 -- - 使ってなければ問題ない？ -- - Androidの古いバージョンでは(Android 3 - 4.1) - 標準のWebViewコンポーネントがデフォルトでaddJavascriptInterfaceを使用 - addJavascriptInterface使った覚えがなくても問題が起きる!! - WebView組み込んでるだけで問題がある - こりゃ大変 ---- - アプリが任意のWebページを表示できる = そのアプリの権限で任意コード実行可能 - 通信が改竄されている = そのアプリの権限で任意コード実行可能 - 冗談みたいだけど本当の話 ---- ## こりゃマズイよ - 昨年末に問題について調査 - 権限の弱いアプリでも: アプリケーション一覧の取得などが可能 - 権限の強いアプリ: アドレス帳読み込み、SMS送信 etc ---- ## Androidの安全性 - 公になってないだけ - セキュリティ関係者は知ってる - ちょっと調べれば実証コード手に入る ---- ## 事例 - WebView使ったブラウザアプリ - いくつかのアプリで検証 - Android4.1以下で脆弱なもの - Android4.2以降でも脆弱なもの ---- ## Android4.1以下で危険なもの - アプリ開発者は殆ど悪くない - 標準のWebViewをそのまま使ってるだけで危険 - 他の権限昇格系のバグと組み合わせればWebサイト開いただけで完全掌握 ---- ## Android4.2以降でも危険なもの - いくつか把握 - ブラウザ独自の機能や拡張機能のために、addJavascriptInterfaceを使用 ---- ## Android側での対応 - Android API Level 17 での変更 - 指定したメソッドしか呼び出せないようにすることが可能に - http://commonsware.com/blog/2013/02/18/webview-addjavascriptinterface-change.html - http://android-developers.blogspot.jp/2013/02/security-enhancements-in-jelly-bean.html - 動作対象デバイスが限られることになってしまう ---- ## Android 4.4 で改善 - されている、はず - ApplicationのContextオブジェクトを取得することが出来たクラスが無くなってる - 他にも抜け道があるかもしれない [要調査] ---- ## WebView使ってれば何でも影響を受ける - 広告配信用のSDK(殆どHTMLだよね) - 回線が信用出来ない状況下でも安全にしたければ、全通信SSL必須に ---- ## アプリケーション開発者側はどうすべき？ - 古いAndroidでもなんとか出来ないこともない - Chrome/Operaは実際に影響受けない(標準WebView使ってないから) - 独自でWebKit組み込むとか、うまいこと上書きするとか。 - OS側のバグにどこまで対処すべきかという問題 ---- - 影響広範すぎるのでOS側で対処してくれるのが望ましいが・・・ - 現実的にアップデート困難な端末が多数ある - 「IEの問題だろ！！」と言いつつ対応してきた歴史と似てる ---- # アプリ間連携に関する問題 ---- ## アプリケーション間連携に係るもの - シングルサインオンとか - Webサイト間 - アプリケーション間 ---- ## 認証、OpenIDやOAuth、プラットフォームSDK - 強制的に認可させてしまうようなもの - 他人に成りすましてログイン出来てしまうもの - 正規のアプリ以外に強制的に認可できてしまうもの ---- ## OpenID, OAuthのCSRF問題 - ライブラリ使って普通に実装しただけ、で現状防げてない問題がある ---- ## Facebook SDKによるもの - そのユーザー用の「別アプリ」のアクセストークンをアプリに入力 - カスタムURLスキームで受け渡す - ユーザー情報取得 → ログインに使用 - 悪意のあるアプリ開発者が別アプリに成りすましログイン可能になる ---- ## 対策 - 「そのアプリ用に発行されたtokenかどうかの確認」 - http://oauth.jp/blog/2012/02/08/ios-sdk/ ---- ## 対策2 - アプリケーション間の遷移を調べる - 呼び出し元のアプリを調べて、検証する - 概ね安全 - 抜け道がある ---- ## 呼び出し元の検証: Androidのケース - 2013年7月: Android OS においてアプリの署名の検証が不十分な脆弱性 - 古い端末 + 野良アプリを考慮する場合: package signatureが宛にならない - 正規のアプリに限定したい処理が野良アプリからでも叩けることに ---- ## 呼び出し元の検証: iOSのケース - openURLで他のアプリケーション起動 - 呼び出し元アプリのBundle IDを取れる - WebView内のリンククリックでも付いちゃうよ - 任意のWebページを表示するような機能があるなら呼び出し元アプリ情報はアテにならない ---- ### 悪意のあるアプリを入れなければ問題ない？ - 概ねその通り。 - 不自由なマーケットに依存したセキュリティ - App Store, Google Playに配布形態が限定 - この考えで行くとアプリ自由に開発/配布できない世の中になってしまう ---- ### これからアプリ間連携作る人へのアドバイス - 重要な処理は必ずユーザー操作を介在させたほうが良い - 信用できるアプリ同士に限定したつもりであっても - 本当に限定できてる？ ---- ### プロトコルレベルでの設計ミス - 後から方向修正が困難。古いバージョンのアプリが残ると厄介。 - SDKとして配布 → 古いバージョンが市場に残り続ける - 最初から正しい設計指針を持つことが大事 ---- ### それでも間違えてしまったら - バージョンアップ機構と適切なアナウンス - 処理を完全にアプリ内で完結させると危険 - サーバーサイドで修正できる余地を残しておく ---- ### 開発者のジレンマ - 古いバージョンが残っているので詳細を公開できない - security fix なのに bug fix と告知 - 深刻なバグは強制バージョンアップの仕組みを。 - サーバー側で対処できるような仕組みのほうが安全？ ---- ### Mailboxの事例 - Gmailを一度Mailboxのサーバー経由で受信 - そのためサーバー側でのフィルタでも対応できる - その気になれば運営者からメールを盗み見ることが出来てしまう - データがどこに保存しているのか曖昧な世界 ---- サーバーサイドから実行コードすら更新できるようになっていたほうが 迅速にバグ修正できるけれど、 それはそれで安全かどうかの検証も不可能な世界 ---- ### スマホアプリの現状 - 権限の強いWebViewにリモートのHTMLやJSが読み込まれる - そのアプリケーションが安全か、信用できるか、単体で分からない - 解析しても動的に受信するソースとセットじゃないと判断できない -- - 第三者による安全性の担保が困難 - ユーザーから見て安全かどうか判断が難しい ---- ## 安全なアプリを作るために ---- - これまで発見、対処してきた経験から ---- ### 1. 根本的な対策を - JavaScriptフィルタする前にWebViewの権限落とせ ---- ### こんなふうに考えがち - JavaScriptをフィルタするのが対策 - WebViewの権限を落とすのが保険的対策、フェイルセーフ設計 ---- ### 順番逆にしませんか？ - バグがあっても安全にするのがフェイルセーフ - "適切な権限"で動いてないのは、そもそもおかしい ---- ### unixの世界観を参考に - root権限で何もかも動いてるようなもの - 適切な権限で動かすのがまず大前提 -- - ファイルパーミッション - WebであればSame origin policy - 原始的な保護機構は枯れててバグも少ないことが期待できる ---- ### 2. 攻撃シナリオと保護資産を意識する ---- ### 例えば - ユーザーが怪しいWiFi使った - ユーザーが携帯電話落とした - 「自己責任でしょ」と言いたいところ ---- ### SSL使うなら - 回線が信用できなくても安全にするのが目的 - その前提に立たなければ意味が無い -- ### 暗号化 - ストレージ上の暗号化 - 解読されるまでの時間稼ぎ - 物理的に盗まれても大丈夫なようにするのが目的 ---- ### 良くあるケース - Android + WebViewの脆弱性 - 通信が改竄されてる場合にアプリの権限で任意コード実行 ---- ### 偽アクセスポイント問題 - 特定のSSIDで自動接続するような設定の端末が非常に多い - 罠仕掛けようと思えば簡単 ---- ### 通信改竄されるとクリティカルになるケース - ケースバイケース - 判断できなかったらとにかくHTTPS使ったほうがいい ---- ### コストの関係で難しい場合は - 画像や動画なら。 - Mozilla の Active/Passive content 判断を参考に - https://developer.mozilla.org/en-US/docs/Security/MixedContent -- - あるいは署名やハッシュ値の検証とセットでHTTPを使う - アプリケーション本体に検証処理を組み込めばいい ---- ### 3. OSのバグと適度に向きあう ---- - iOS5,6: アプリ内XSSでOSのアドレス帳が読める - Android: 標準WebView使ってるアプリ全般が危険 ---- ### 開発者はどうすべきなのか？ - ユーザーは実際に古いバージョンのOSを使ってる - アップデート困難な端末が多数市場に残っている ---- ### Webサイトとスマホアプリの違い Webの場合 - geocitiesでJavaScript書けても「脆弱性だ」とは言わない - 本来動いちゃいけないscriptが動かせたらXSS -- スマホの場合 - 保護すべき機密情報を持たないアプリでも - アドレス帳が読めてしまったりOSの機能を叩けたり - 通信が改竄された場合の影響が無視できないほど大きかったり ---- ### 自分の考え - アプリ入れても入れなくても起こる問題ならOSの問題 - そのうちOS側のバージョンアップで勝手に安全に？？ - あまり期待しないほうがいい - そのアプリ固有で増加するリスクは対処した方がいい -- - 影響の大きい問題は個々のアプリが対策してくれないと悪循環になる - 公表されない → 周知されない → 個人の開発者は全く知らない - WebViewに起因する問題 - セキュリティ関係者は知ってるけど開発者が殆ど知らないのでは。 ---- 以上 ---- 質疑応答 ----