• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
モバイルアプリケーションセキュリティ101
 

モバイルアプリケーションセキュリティ101

on

  • 1,672 views

 

Statistics

Views

Total Views
1,672
Views on SlideShare
1,672
Embed Views
0

Actions

Likes
1
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    モバイルアプリケーションセキュリティ101 モバイルアプリケーションセキュリティ101 Presentation Transcript

    • モバイルアプリケーション セキュリティ101Security Assurance Group, System Security Oiffice, DU, Rakuten, Inc. Tokuji Akamine, Chris Liu
    • 自己紹介 •  Tokuji Akamine 赤嶺徳治 @tokujia OWASP Japan アドバイザリボードメンバ セキュリティアシュアランスグループマネージャ リードセキュリティエンジニア 楽天レッドチームメンバ •  Chris Liu シニアセキュリティエンジニア 楽天レッドチームメンバ 2
    • アジェンダ •  スマートデバイスの成長 •  OWASPモバイルセキュリティプロジェクト•  モバイルアプリ開発におけるセキュリティ的課題 •  OWASPモバイルトップ10リスク•  OWASPモバイルトップ10コントロール
    • スマートデバイスの成長 •  Nearly 1 Billion Smart Connected Devices Shipped in 2011 with Shipments Expected to Double by 2016, According to IDC Source: IDC http://www.idc.com/getdoc.jsp?containerId=prUS23398412
    • モバイルアプリ開発におけるセキュリティ的課題 •  デバイスの盗難、紛失リスクが高い •  容易にROOT化、脱獄が可能•  プラットフォーム、デバイスごとに異なる機能•  パッチ、アップデートが困難 •  スクリーンが狭い •  キー入力の困難性 etc. 5
    • OWASPモバイルセキュリティプロジェクト • OWASP Mobile Security Projecthttps://www.owasp.org/index.php/OWASP_Mobile_Security_Project“The OWASP Mobile Security Project is a centralized resource intended togive developers and security teams the resources they need to build andmaintain secure mobile applications.”
    • OWASPトップ10モバイルリスク(v1.0候補)  1.  脆弱なデータストレージ2.  脆弱なサーバサイドコントロール3.  不完全なトランスポート層の保護4.  クライアントサイドインジェクション5.  脆弱な認証、認可6.  不適切なセッション管理7.  信頼できない入力によるセキュリティ判断8.  サイドチャネルデータ漏洩9.  脆弱な暗号10. 機密情報の漏洩
    • OWASPトップ10モバイルコントロール  1. モバイルデバイス上の機密データの識別と保護2. デバイス上のパスワードクレデンシャルの安全な管理3. 送信時における機密データの保護4. 適切なユーザ認証/認可およびセッション管理の実装5. バックエンドAPIとサーバプラットフォームの継続的堅牢化6. サードパーティサービス/アプリケーションとのセキュアなデータ連携7. ユーザデータの収集と使用に対する承諾の収集、保存への注意8. 有料リソース(電子ウォレット、SMS、通話等)に対する権限のないアクセスを防止する対策の実装9. モバイルアプリケーションのセキュアなディストリビューション/プロビジョニング10. コードのランタイムインタプリテーションのエラー確認 日本語訳:https://docs.google.com/document/d/1QOWOrsAo-33bHLdAZksKa4F_8_A_6XndoDF6ri4na_k/edit?pli=1
    • 1.  モバイルデバイス上の機密データの識別と保護  •  機密データはクライアントエンドデバイスではなくサーバに保存する。•  もし暗号化されていないのであれば機密データを保存/キャッシュしない。•  共有ストレージは信頼できないものと見なす。情報は共有ストレージから 想定していない方法で容易に漏洩する可能性がある。例:- ワールドリーダブルファイル(Android) fos = openFileOutput(“secret.txt", Context.MODE_WORLD_READABLE);- スクリーンショットキャッシュ (iOS) /var/mobile/Library/Caches/Snapshots/myapp/ UIApplicationAutomaticSnapshotDefault-Portrait@2x.jpgケーススタディ:- Skype Information Leakage due to file http://www.androidpolice.com/2011/04/14/exclusive-vulnerability-in-skype- for-android-is-exposing-your-name-phone-number-chat-logs-and-a-lot-more/
    • 2.  デバイス上のパスワードクレデンシャルの安全な管理   •  パスワードを使用する代わりに、デバイス上に長期間安全に保存できる 認可トークンの使用を検討する。 •  パスワードおよびキーがキャッシュまたはログに出力されていないか確 認する。 •  SMSはセキュアチャネルではなく、機密情報を送信する上で信頼するこ とはできない。例:- Shared Preferences、KeyChainへのパスワードの保存 ROOT化、脱獄化により奪取可能。→デモ1ケーススタディ:- Facebook, Dropbox Security Hole http://www.mobileusers.com/2012/04/06/iphone-and-android-facebook- app-security-hole-gives-green-light-to-identity-theft/- Discovering a Major Security Hole in Facebooks Android SDK http://blog.parse.com/2012/04/10/discovering-a-major-security-hole-in- facebooks-android-sdk/
    • 3.  送信時における機密データの保護   •  機密情報を無線/有線にて送信するときには、アプリケーションは(SSL/ TLSのような)エンドツーエンドの安全な通信チャネルの使用を強制する べきである。 •  強度の高い暗号化アルゴリズムとキー長の使用を強制する。署名されて いない証明書を許可せず、信頼できる認証局のみを許可する。SSL接 続検証を無効または無視しない。例:- 不適切なSSL接続検証- 機密データの平文での送信ケーススタディ:- LinkedIn Privacy Issue http://blog.skycure.com/2012/06/linkedout-linkedin-privacy- issue.html- Nordea mobile bank app MITM attack http://www.encripto.no/forskning/whitepapers/ Nordea_mobilbank_android_multiple_vulnerabilities.pdf
    • 4.  適切なユーザ認証/認可およびセッション管理の実装   •  適切な強度のユーザ認証をアプリケーションに求める。初回の登録時に パスワード強度に関してフィードバックを提供することは有用かもしれない。 •  最初の認証後、セッション管理を適切に実施することは重要である。認証 クレデンシャルまたはトークンの送信を後続のリクエストに対しても要求 する。 •  エントロピーが高く推測不可能なセッション識別子を使用する。 •  (デバイス識別子よりも)エンドユーザの識別子に紐付いた認証を使用する。例:- 脆弱なクライアントサイド認証 →デモ2ケーススタディ:- Linking UDIDs to OpenFeint user accounts https://api.openfeint.com/users/for_device.xml?udid=XXX http://corte.si/posts/security/openfeint-udid-deanonymization/ index.html
    • 5.  バックエンドAPI(サービス)と   プラットフォーム(サーバ)の継続的堅牢化   •  OS、Webサービスおよびその他のアプリケーションコンポーネントに対し て最新のセキュリティパッチを適用した堅牢な設定で、バックエンドプラッ トフォーム(サーバ)を稼働させる。 •  Webサービス、RESTおよびAPIはWebアプリケーションと同様の脆弱性 を持つ。脆弱性が存在するか確認するためにバックエンドのWebサー ビス、REST、およびAPIへのテストを実施する。ユースケーステストに加 えて不正なケーステストを実施する。例:- 通常のWebアプリケーションやWebサービスの脆弱性 (XSS、SQLインジェクション等)
    • 6.  サードパーティサービス/アプリケーション   とのセキュアなデータ連携  •  モバイルアプリケーションが使用するサードパーティコード/ライブラリの 安全性/信頼性を入念に検査する。•  モバイルアプリケーションにて使用されている全てのサードパーティフレ ームワーク/APIに対するセキュリティパッチに関してトラックする。•  信頼できないサードパーティアプリとの送受信データをアプリケーション 内で使用する前に、検証に特別な注意を払う。例:- 広告用API による情報漏洩- NDKによるC言語の脆弱性ケーススタディ:- アップログ http://matome.naver.jp/odai/2131778619234854901 ※利用者情報を、本人に明示しないまま集めていた問題
    • 7.  ユーザデータの収集と使用に対する承諾の   収集.保存への注意   •  個人データを使用に関するプライパシーポリシーを作成し、特に承諾の 判断を行うときにユーザが確認できるようにする。 •  アプリケーションがPIIを収集していないか確認する。 •  PIIの送信に対する承諾記録をユーザが確認できるようにする。例:- 不必要なパーミッションの要求(Android)- PII Transferケーススタディ:- LinkedIn、カレログ、Angry Bird、the Movie、Path、etc.- What They Know by WSJ http://blogs.wsj.com/wtk-mobile/- Unauthorized iPhone And iPad Apps Leak Private Data Less Often ThanApproved Ones http://www.forbes.com/sites/andygreenberg/2012/02/14/unauthorized- iphone-and-ipad-apps-leak-private-data-less-often-than-approved-ones/
    • 8.  有料リソースに対する権限のない   アクセスを防止する対策の実装  •  有料リソースへのアクセスログを否認不能な形式で保存し、エンドユーザが確認 できるようにする。権限のないアクセスからログを保護する。•  有料リソースの異常な使用パターンを確認し、再認証を要求する。•  有料リソースに対する全てのAPIコールを認証する。•  ウォレットAPIコールバックが平文でアカウント/料金/支払いまたは商品情報 を送信しないようにする。例: - Android exported属性 →デモ3 - デバイス内での購入状況管理ケーススタディ: - Crack In-App Purchase in iOS with iAP Cracker http://jailbreakstory.com/2011/09/crack-in-app-purchases-in-ios-with- iap-cracker/
    • 9.  モバイルアプリケーションのセキュアな   ディストリビューション/プロビジョニング  •  アップストアによる承認のための要求事項とそれによる遅延を考慮に入れ、アプ リケーションはセキュリティパッチのためにアップデートを行うことを許可するよう 設計され、提供されなければならない。•  リモートキル機能の提供•  フィードバックチャネル
    • 10.  コードのランタイムインタプリテーションのエラー確認  •  ランタイムインタプリテーションとランタイムインタプリタに提供される機能を最小 限にする。•  最小権限でインタプリタを実行する。•  インタープリタに対するファズテスト•  コードがインタプリットするのがいつもテキストとは限らないことを注意する。例:- クラッシュ分析 /data/tombstones/ (Android)
 Xcode – Organizer – Device Logs(iOS) - ファジングテスト Monkey: ユーザ行為のファジング
    • リファレンス•  OWASP Mobile Security Project https://www.owasp.org/index.php/OWASP_Mobile_Security_Project•  iOS Developer Library Secure Coding Guide http://developer.apple.com/library/ios/#DOCUMENTATION/Security/Conceptual/ SecureCodingGuide/Introduction.html https://developer.apple.com/library/mac/documentation/security/conceptual/ SecureCodingGuide/SecureCodingGuide.pdf•  iOS Security released by Apple on May 2012 http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf •  Iphone data protection tools http://code.google.com/p/iphone-dataprotection/•  class-dump-z http://code.google.com/p/networkpx/wiki/class_dump_z•  Cycript http://www.cycript.org/•  Hacking and Securing iOS Applications by Jonathan Zdziarski•  iOS Hackers Handbook by Charlie Miller, Dino DaiZovi, and others•  Smart Phone Security: How (Not) To Summon The Devil http://crypto.hyperlink.cz/files/rosa_scforum12_v1.pdf•  Seven Ways to Hang Yourself with Google Android http://crypto.hyperlink.cz/files/rosa_scforum12_v1.pdf•  Android Developers Designing for Security http://developer.android.com/guide/practices/security.html 19
    • Thank you !!tokuji.akamine@mail.rakuten.comyulu.liu@mail.rakuten.com 20