Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)
•
25 gostaram•12,968 visualizações
Why and How should you approach to Android Security in architecting phase, implementation phase, and operation phase. This includes what type of secure planning should be considered in term of business domain, what type of universal secure coding should be done. It also talks about how should you store keystores and its password in safe manner.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)
Semelhante a Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2) (20)
Mais de Kengo Suzuki
Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)
- 2. About Me • 名前 • Twitter: @kengoscal • Github: ken5scal • 職歴 • セキュリティ系(2011年11月∼) • Money Forward所属（2014年11月∼）
- 3. 私とAndroid • 2015年: 1月からAndroid開発に参加 • Lollipopから • 先輩開発者が経験した辛さを伝説としてのみ知る
- 4. 今回話すことの技術的範囲
- 5. アウトライン • 背景 • どこからセキュア開発を学ぶか？ • 現状の課題 • 設計フェーズ、実装フェーズ、運用フェーズ • まとめ
- 6. 訴訟 • 登場人物 • A社 -> 発注側。Eコマースの受注システムを設計∼保守込みで契約 • B社 -> 開発側（受注側) • 事件 • コードレベルでのセキュリティ対策不足によりクレカ情報が流出 • A社はB社を 債務不履行"と損害賠償で民事訴訟 • ただし契約には"本件ウェブサイトのセキュリティ対策を講じる義 務を負うことは規定されていなかった" [引用]http://www.softic.or.jp/semi/2014/5_141113/op.pdf
- 8. 判決 • IPA/経産省が特定の攻撃に対する対策を推奨してい ため、 被告には重過失が認められるというべき と された。 [引用]http://www.softic.or.jp/semi/2014/5_141113/op.pdf
- 12. なにより • ユーザー！ • 自分の情報が流出するという損 • 漏洩発覚時の対応をしなければいけない損 • 本当にメンドくさいです（実体験） • 漏洩有無の確認、漏洩範囲の確認、漏洩内容の確認、 漏洩情報の影響の判断、漏洩情報の変更依頼、漏洩 対策の確認, etc. etc
- 13. なので • セキュリティ気にした開発しよう！ • 皆で幸せになりたい • 脆弱性はバグなので品質向上に勤めよう！
- 14. アウトライン • 背景 • どこからセキュア開発を学ぶか？ • 現状の課題 • 設計フェーズ、実装フェーズ、運用フェーズ • まとめ
- 16. 当然、IPAから探してみる
- 17. IPAのAndroid学習ツール • 学習・点検ツールがあった！ • さすがIPA! そこに痺れる！ 憧れる! [引用: IPA 情報処理推進機構] https://www.ipa.go.jp/security/vuln/ancole/
- 18. でも・・・
- 19. でも・・・
- 20. でも・・・
- 21. でも・・・
- 22. この世に希望はないのか…
- 23. 希望(書籍)ありました
- 24. • Android Security - 安全なアプリケーションを作 成するために(著: タオソフトウェア株式会社) 希望（書籍） - その1 • 包括的なセキュリティ開発のポイント • セキュリティ開発の入門として最適 • 殺られた事例を紹介 • 実装も記載 • ちょっと昔(2012年)
- 25. 希望（書籍） - その2 • 最強 • 更にセキュアにしたい人向け • ケースに応じたガイドが嬉しい • サンプルコードも豊富 • 最新のバージョンを追従 • 無料 • 業界基準ではない • Androidアプリのセキュア設計・セキュアコーディ ングガイド(著: JSSEC)
- 27. 完
- 28. 完
- 30. 数値から見るセキュリティ • 依然、93%のアプリに脆弱性リスクが存在 • 暗号通信が解読・改ざんされるリスクのあるアプリ は増加! [引用: Sony Digital Network Application] Android脆弱性調査レポート2015
- 31. 事例から見るセキュリティ [引用: FireEye] https://www.fireeye.com/blog/threat-research/2015/08/ another_popular_andr.html • LogCatに機密情報を流してた • トークンなどを平文でネットにな がしてた • トークンが永続化されていた • パスワードが弱い暗号方式で暗号 化されてた
- 32. 事例から見るセキュリティ [引用: FireEye] https://www.fireeye.com/blog/threat-research/2015/08/ another_popular_andr.html • WebView上の通信でhttp通信 を使ってたので、通信を改竄さ れる
- 33. 書籍のカバー範囲なのに なぜ？
- 34. アウトライン • 背景 • どこからセキュア開発を学ぶか？ • 現状の課題 • 設計フェーズ、実装フェーズ、運用フェーズ • まとめ
- 35. Androidのセキュリティ範囲 • 範囲 • ファイルアクセス権限、APKファイル保護、パー ミッション、Activity, Broadcast, Service, Content Provider、インテント、暗号化、 SQLite、Logcat, WebView, Account Manger, https, プライバシー情報、パスワード入力画面, アプリケーション保護, 証明書, 新しい Permission, Clipboard, etc, etc
- 36. Androidのセキュリティ範囲 • 範囲 • ファイルアクセス権限、APKファイル保護、パー ミッション、Activity, Broadcast, Service, Content Provider、インテント、暗号化、 SQLite、Logcat, WebView, Account Manger, https, プライバシー情報、パスワード入力画面, アプリケーション保護, 証明書, 新しい Permission, Clipboard, etc, etc ・・・ヒロくね?
- 37. 開発者の責任範囲 • セキュリティ範囲 • ファイルアクセス権限、APKファイル保護、パーミッション、Activity, Broadcast, Service, Content Provider、インテント、暗号化、SQLite、 LogCat, WebView, Account Manger, https, プライバシー情報、パスワード 入力画面, アプリケーション保護, 証明書の管理方法, 新しいPermission, Clipboard, etc, etc • に加えて(自分の体験例) • 新規開発（約２ヶ月）、サービスのKPIに沿った実装の提案, 全体の設計, コン ポーネントのライフサイクルを考慮したデータのやり取り, カスタムViewの作 成, デザイナーとの自社ブランドとMaterialDesignガイドに沿ったデザインの 検討、Web側担当者とのAPI仕様検討, カスタマーサポートからのバグ報告対応, CI環境の整備、テストの作成、ASO/SEO対策, etc, etc
- 38. 開発者の責任範囲 • セキュリティ範囲 • ファイルアクセス権限、APKファイル保護、パーミッション、Activity, Broadcast, Service, Content Provider、インテント、暗号化、SQLite、 LogCat, WebView, Account Manger, https, プライバシー情報、パスワード 入力画面, アプリケーション保護, 証明書の管理方法, 新しいPermission, Clipboard, etc, etc • に加えて(自分の体験例) • 新規開発（約２ヶ月）、サービスのKPIに沿った実装の提案, 全体の設計, コン ポーネントのライフサイクルを考慮したデータのやり取り, カスタムViewの作 成, デザイナーとの自社ブランドとMaterialDesignガイドに沿ったデザインの 検討、Web側担当者とのAPI仕様検討, カスタマーサポートからのバグ報告対応, CI環境の整備、テストの作成、ASO/SEO対策, etc, etc ・・・キツくね?
- 42. Build Security Inの紹介 • 最近セキュリティ業界で盛り上がってる • Build Security In is a collaborative effort that provides practices, tools, guidelines, rules, principles, and other resources that software developers, architects, and security practitioners can use to build security into software in every phase of its development. • by US-CERT(米国国土安全保障省（DHS）配下の情報セキュリティ対策組織) [引用]http://www.softic.or.jp/semi/2014/5_141113/op.pdf
- 43. Build Security Inの紹介 • 最近セキュリティ業界で盛り上がってる • ソフトウェア開発の全工程にセキュリティを組み 込めるようなベスト・プラクティス、ツール、ガイ ドライン等のリソースを開発者などに提供する協同 的な取り組み [引用]http://www.softic.or.jp/semi/2014/5_141113/op.pdf
- 46. アウトライン • 背景 • どこからセキュア開発を学ぶか？ • 現状の課題 • 設計フェーズ、実装フェーズ、運用フェーズ • まとめ
- 47. 設計フェーズのセキュア開発 • 実装そのものではない • 開発計画へセキュリティの要件を組み込む • サービス上のリスクに対する脅威と脆弱性の洗出し • リスクの顕在化蓋然性や影響に基づくやるやら判断
- 48. なぜ設計段階でやるのか？ • コスパがいい • 設計時より運用開始後の対策費は60 100倍 • 80%の脆弱性は設計段階で生まれる（ソース未確認…) [引用:NRI] http://fis.nri.co.jp/ja-JP/publication/kinyu_itf/backnumber/
- 49. Android設計時のポイント • ココらへんについて特に注意を払いたい（kengoscal的に） • 手戻り工数・影響が大きいもの • データの保管方法 • セッションの保持のしかた • Permission • 3rd Party製の広告モジュール • WebViewで何処で使って、何をしたいか • 暗号化方式 • 連携アプリの有無（コンポーネント間の連携）
- 50. Case: Money Forward • のB2B版開発をイメージ • サービス紹介: 金融機関に資産情報をスクレイピン グにいって、それを一元化するアプリ
- 51. データの保存方法 • アプリで扱うデータの重要度を考える • 金融機関のログインフォーム関連の情報: 重要度低 • データ量が大きいのでSQLite使って平文で保存 • パスコード: 重要度中 • パスコードは暗号化しておきたいのでFileに書き出す • AES/CBC/pkcs5padding • 他の情報: 重要度高 • ローカルに保存しない
- 53. WebView • FAQと利用規約を表示させるくらい • Chrome Custom Tabを使う
- 54. 連携アプリの有無 • 自社のアプリと連携するための独自Permissionを 作る • 長いので「Androidアプリのセキュア設計・セキュ アコーディングガイド」を参照されたし • 4.1.1.4. 自社限定 Activity を作る・利用する • 5.2.1.2. 独自定義の Signature Permission で 自社アプリ連携する
- 55. Anti Case: Skype • ユーザーの個人情報・チャット履歴が流出した • 独自生成したディレクトリ・ファイル下に保存し た -> AndroidOSによる保護機能がきかなかった • DBファイルも平文で保存されていた • Build in Securityの「設計フェーズ」において「デー タの保管方法」について設計から考えてれば、防げ た（かも）
- 56. アウトライン • 背景 • どこからセキュア開発を学ぶか？ • 現状の課題 • 設計フェーズ、実装フェーズ、運用フェーズ • まとめ
- 57. 実装フェーズのセキュア開発 • あるある系のチェックが主 • https通信における証明書検証漏れ • WebViewのaddJavascriptInterface • LogCat • ここは開発者として抑えておいた方がいいとおもう
- 58. 基本的に実装方法は
- 60. 本に記載されていないもの • URLConnectionクラスにおけるHTTPヘッダイン ジェクション対策 • setRequestProperty/addRequestPropertyを利 用していると、HTTPヘッダを通じて任意のコード をどこからでも実行される可能性がある • 根本対策: OkHttp2.5.0以上にする • ワークアラウンド: ヘッダの入力値チェックをする • 詳細: https://jvn.jp/vu/JVNVU99757346/
- 61. ヘッダの入力値チェック [引用:Square] https://github.com/square/okhttp/blob/master/okhttp/src/main/java/ private void checkNameAndValue(String name, String value) { if (name == null) throw new NullPointerException("name == null"); if (name.isEmpty()) throw new IllegalArgumentException("name is empty"); for (int i = 0, length = name.length(); i < length; i++) { char c = name.charAt(i); if (c <= 'u001f' || c >= 'u007f') { throw new IllegalArgumentException(String.format( "Unexpected char %#04x at %d in header name: %s", (int) c, i, name)); } } if (value == null) throw new NullPointerException("value == null"); for (int i = 0, length = value.length(); i < length; i++) { char c = value.charAt(i); if (c <= 'u001f' || c >= 'u007f') { throw new IllegalArgumentException(String.format( "Unexpected char %#04x at %d in %s value: %s", (int) c, i, name, value)); } } } • 対策済みのokhttpからコピペ
- 62. アウトライン • 背景 • どこからセキュア開発を学ぶか？ • 現状の課題 • 設計フェーズ、実装フェーズ、運用フェーズ • まとめ
- 64. 証明書・KeyStoreのリスク • アプリが制御下から離れるリスク • 紛失した場合: アプリのアプデができなくなる • 盗難された場合: アプリの乗っ取り • CaseStudy: • 見た目全く同じで、金融機関ログイ ン時の情報を故意のURLに流す
- 65. ありがち?な運用環境
- 66. ローカル開発環境A用 fetch & push sign & deploy D用 C用 B用 A用
- 67. 何が問題なのか
- 68. 問題 • 開発端末毎に独立してるのでkeystoreの管理がし にくい • 攻撃等によるkeystoreが漏洩するチャネルが広い • 攻撃手法や攻撃対象などが広いという意味 • 漏洩発覚時の追跡が難しい
- 70. ローカル開発環境 A用 Fetch & Push + B用 C用 Fetch or Hook Build & Deploy Backup
- 71. ローカル開発環境 A用 Fetch & Push + B用 C用 Fetch or Hook Build & Deploy Backup ローカルにはkeystoreを置かない
- 72. ローカル開発環境 A用 Fetch & Push + B用 C用 Fetch or Hook Build & Deploy Backup リリースビルドはCIツールのジョブからのみ keyStoreを集約 開発者は基本Web/Chatからジョブをキックするのみ sshなどのリモート操作は限定された役職のみ
- 73. ローカル開発環境 A用 Fetch & Push + B用 C用 Fetch or Hook Build & Deploy Backup apkは手動・自動でdeployツールもしくはStoreにアッ プロードして、端末に配布
- 74. ローカル開発環境 A用 Fetch & Push + B用 C用 Fetch or Hook Build & Deploy Backup CIツール紛失などでCI上のkeyStoreが消えた場合にrestoreでき るように、keyStoreをストレージにバックアップ。 これも限定された業種・役職のみがアクセス可能
- 75. ローカル開発環境 A用 Fetch & Push + B用 C用 Fetch or Hook Build & Deploy Backup CI環境に限らず、委託や受託の場合もkeyStoreのバックアップは さっさと取っておくのが安
- 76. アウトライン • 背景とゴール • どこからセキュア開発を学ぶか？ • 現状の課題 • 設計フェーズ、実装フェーズ、運用フェーズ • まとめ
- 77. まとめ • 皆(ユーザー・開発者・発注者)で幸せになりたい • その1要素としての・品質としてのセキュリティ • 教材は っている • 教材がおもすぎる場合は、開発段階ごとに必要なセ キュリティ施策を分解する
- 79. ご清聴 ありがとうございました
- 80. おまけ
- 81. Nにおけるセキュリティ • Network Security Configuration • Key Attestation • Permission
- 82. Network Security Configuration • コードで記述した証明書関連の動作をxmlで書ける • 信頼するCAのホワイトリスト化 • 証明書ピニング • 平文通信の除外
- 83. Key Attestation • Hardware-backed keystores のヘルパーみたい なイメージ • Hardware-backed keystoresの検証をしてくれ る？
- 84. Permission • GET_ACCOUNTS: • Deprecated • ACTION_OPEN_EXTERNAL_DIRECTORY(NEW • App専用のディレクトリを作成・権限付与