この文書は2016年以降更新されていません

iOS 開発者のためのチートシート

OWASP 作成
ジャンプ先: 移動検索
Cheatsheets-header.jpg

最終改訂日 (yy/mm/dd): 2015/07/18

はじめに

このドキュメントは、iOS アプリの開発者を対象に、Apple の iOS オペレーティングシステム向けのセキュアなアプリを開発するときに重要となる項目について、その基本を説明することを目的としています。このドキュメントは、「OWASP Mobile Top 10 Risks 」(OWASP モバイルリスク Top 10) 一覧に基づいています。

基礎

ユーザーの観点から、自分の iOS デバイスを守るためにできる最善のことを 2 つ挙げるとすれば、強力なパスワードを有効にすることと、ジェイルブレイクしないことです。しかし、開発者にとっては、このどちらも問題を含んでいます。アプリのサンドボックス環境内では、いずれも検証できないからです。(Appleは以前、ジェイルブレイクしているかどうかデバイスをテストするための API を提供していましたが、その API は 2010 年に廃止されました。)企業の場合、強力なパスワードとその他のさまざまなセキュリティ関連の設定をモバイルデバイス管理 (MDM) 製品で管理し、強制できます。小規模な会社や複数のデバイスを所有する個人は、Apple の iPhone 構成ユーティリティ (http://www.apple.com/support/iphone/enterprise/) と Apple Configurator (Mac App Store で入手可能) を使用することで、安全な構成プロファイルを構築して複数のデバイスに展開できます。

OWASP モバイルリスク Top 10 への対策

安全でないデータストレージ (M1)

モバイルデバイスの個人ユーザーが直面する最大のリスクは、間違いなく、デバイスの紛失や盗難によるものです。この場合、デバイスに保存されている情報が、デバイスを見つけた人や盗んだ人の目にさらされてしまいます。アプリが保存するデータを適切に保護する責任の大部分は、デバイス上の各アプリにあります。Apple iOS には、データを保護するためのメカニズムがいくつか用意されています。これら組み込み済みの保護メカニズムは、大半の個人ユーザーレベルの情報の保護に十分な機能を持っています。財務データなど、より厳重なセキュリティ要件が求められる場合は、これらApple が提供するメカニズムを超える追加の保護機能をアプリケーションに組み込むことができます。

対策

一般に、アプリでは、その基本タスクの実行に必要なデータだけをローカルに保存することをお勧めします。これには、システムロギングなどのサイドチャネルデータも含まれます (下の M8 を参照)。どのような形式であれ、機密データを、アプリのサンドボックス内 (~/Documents/* など) のプレーンテキストデータストレージに保存することは絶対に避けてください。個人ユーザーレベルの機密データは、Apple が提供する API を使用して安全なコンテナーに保存します。

  • ユーザー認証の資格情報やセッショントークンなど、少量の個人ユーザーレベルの機密データは、デバイスのキーチェーンに安全に保存できます (Apple の「iOS Developer Library」の「Keychain Services Reference」を参照)。
  • より大量の、あるいは、より一般的な種類の個人ユーザーレベルの機密データには、Apple のファイル保護メカニズムを使用できます (保護オプションについては「NSData Class Reference」を参照)。
  • 通常の個人ユーザーレベルの機密度を超えるデータについては、どうしてもローカルに保存する必要がある場合は、Apple の暗号化に固有の問題 (例: 暗号化鍵がユーザーのデバイスパスコードで暗号化されている。通常は 4 桁の PIN) に煩わされることのないサードパーティのコンテナー暗号化 API の使用を検討してください。例えば無償で提供されているSQLcipher (http://sqlcipher.net を参照) などがあります。これを行う際は、適切なキー管理が極めて重要ですが、このドキュメントでは扱いません。
  • キーチェーンに保存するアイテムについては、最もセキュアな API 指定である kSecAttrAccessibleWhenUnlocked (iOS 5/6 ではデフォルト) を使用します。
  • 機密情報の保存に NSUserDefaults は使用しないでください。
  • NSManagedObects を使用するデータ / エンティティはすべて、暗号化されていないデータベースファイルに保存されることに注意してください。

脆弱なサーバー側制御 (M2)

大部分のサーバー側制御は、現にサーバー側で処理する必要がありますが (「Web サービスのセキュリティに関するチートシート」でもそのように述べています)、サーバーで行う作業を助けるためにモバイル上でできることがいくつかあります。

対策

一般的な一連のセキュリティ要件に対応するようにモバイルクライアントとサーバーを設計し、実装します。たとえば、サーバー上で機密とされている情報は、クライアント側でも同じく十分な注意を払って取り扱ってください。 すべてのクライアント側入力データに対して徹底的な入力値検証と正規化を実施します。正規表現やその他のメカニズムを利用して、許容できるデータだけがクライアント側のアプリケーションに入力されるようにします。 信頼できないデータに対しては、できる限り出力エンコードを実行します。

不十分なトランスポート層の保護 (M3)

機密データが傍受される問題は、すべてのネットワーク型アプリケーションに共通の問題であり、iOS モバイルアプリも例外ではありません。

対策

地球上で最も無防備な Wi-Fi ネットワーク上で使用されるという前提のもとで、すべてのアプリを設計し、実装してください。 転送中に保護する必要のあるアプリデータをすべて一覧にまとめます。(ここで保護には機密性や完全性も含みます。)この一覧には、アプリケーションデータ自体に加えて認証トークンやセッショントークンも含めてください。 一覧に記載されたすべてのデータの送受信時に SSL / TLS 暗号化が確実に使用されるようにします。(『CFNetwork Programming Guide』を参照。) アプリでは、適切に検証された SSL 証明書のみを受け入れるようにします。(テスト環境では CA チェーン検証を無効にしていることがよくあります。そのようなコードがアプリにあれば、公開前に確実に削除してください。) 動的テストにより、一覧に記載された全データが、アプリのオペレーション全体を通して適切に保護されていることを確認します。 動的テストにより、偽装や自己署名などがされた証明書を、どのような状況下でもアプリが受け入れないことを確認します。

クライアント側インジェクション (M4)

データインジェクション攻撃は、Web アプリと同様にモバイルアプリでも発生しますが、攻撃のシナリオが異なる傾向にあります (URL スキームを悪用したプレミアムテキストメッセージの送信や通話料の課金など)。

対策

原則として、Web アプリと同じ入力値検証や出力エスケープのルールに従います。 すべてのデータ入力を正規化し、徹底的に検証します。 ローカルの SQLite / SQLcipher 呼び出しにも、パラメータ化クエリーを使用します。 デバイス上のどのアプリも URL スキームを呼び出すことができるので、URL スキームを使用するときは、入力データの検証と取扱いに特に注意してください。 ハイブリッド型の Web / モバイルアプリを構築するときは、アプリのネイティブ / ローカル機能を必要最小限に抑えてください。つまり、UIWebView で表示するコンテンツやアクセスするページを制限し、ユーザーが任意の信頼できない Web コンテンツにアクセスできないようにします。

認可や認証の不備 (M5)

ほとんどはサーバー側の制御ですが、モバイルの一部機能 (一意のデバイス ID など) や一般的な使用例が、ユーザーとその他のエンティティのセキュアな認可や認証に関する問題を悪化させる場合があります。

対策

原則として、Web アプリと同じ認可や認証のルールに従います。 ユーザーやセッションの識別にデバイス ID (UDID、IP アドレス、MAC アドレス、IMEI など) は絶対に使用しないでください。 "帯域外" の認証トークンをユーザーがログインに使用しているのと同じデバイスに送信することは、できるだけ避けてください (たとえば、SMS を同じ iPhone に送信するなど)。 強力なサーバー側認証、認可、およびセッション管理を実装します (control # 4.1-4.6)。 有料リソースに対する API 呼び出しをすべて認証します (control 8.4)。

不適切なセッション操作 (M6)

同様に、セッション操作は一般に主としてサーバー側のタスクですが、モバイルデバイスが従来からの問題を予期せぬ形で増幅しがちです。たとえば、モバイルデバイスでは、多くの場合、"セッション" が従来の Web アプリケーションよりも長く継続します。

対策

ほとんどの場合、Web アプリケーションと同様に強固なセッション管理を実践してください。そこに、モバイルデバイス特有の工夫をいくつか加えます。 セッションの識別にデバイス ID (UDID、IP 番号、MAC アドレス、IMEI など) は絶対に使用しないでください。(control 1.13) デバイスの紛失 / 盗難やセッションの侵害が発生した場合にただちに無効にできるよう、トークンを使った処理を行います。 セッショントークンの機密性と完全性を常時保護します (送信時には常に SSL / TLS を使用するなど)。 セッションの生成には信頼できるソースだけを使用します。

信頼できない入力にもとづくセキュリティ判断 (M7)

iOS は、アプリ同士の通信チャネルを多くは用意していませんが、いくつか存在します。それらのチャネルはデータインジェクション攻撃や悪質なアプリなどにより攻撃者に悪用されるおそれがあります。

対策

入力値検証、出力エスケープ、認可制御を組み合わせて使用することで、このような脆弱性の対策を行うことができます。 すべての入力データを、特にアプリ間の境界で正規化し、徹底的に検証します。 デバイス上のどのアプリも URL スキームを呼び出すことができるので、URL スキームを使用するときは、入力データの検証と取扱いに特に注意してください。 信頼できないデータの出力処理では、出力の意味内容そのものを変更できないように、コンテキストに応じたエスケープ処理を行います。 リソースへのアクセスリクエストに対しては、呼び出し元によるアクセスが許可されていることを確認します。そうするのが適切な場合には、リソースへのアクセスリクエストの許可 / 拒否の判断をユーザーに求めます。

サイドチャネルデータの漏えい (M8)

ここでいうサイドチャネルとは、Web キャッシュ (ブラウザーの速度最適化に使用) やキーボード操作ログ (スペルチェックに使用) など、管理目的または (直接には) 非機能的な目的で一般に使用されるデータ I/O を指します。Apple の iOS は、サイドチャネルデータがアプリから不注意に漏れ出す可能性がいくらかあります。そのデータは、多くの場合、被害者のデバイスを見つけた人や盗んだ人が入手できます。これらの大半は、アプリのプログラミングで制御できます。

対策

ユーザーのデバイスは紛失したり盗まれたりするという前提に立って、すべてのアプリを設計し、実装してください。 まず、デバイス上に存在する可能性のあるサイドチャネルデータをすべて特定します。これらのソースには、少なくとも Web キャッシュ、キーボード操作ログ、スクリーンショット、システムログ、カット& ペースト用バッファーを含めてください。サードパーティのライブラリを使用している場合は、それも必ず含めます。 システムログには、機密データ (資格情報、トークン、PII など) を絶対に出力しないでください。 アプリの最小化時にセンシティブなアプリデータがキャプチャされないように、iOS のスクリーンショット動作を制限します。 極めて機密性の高いデータについては、キーボード操作のロギングを無効に、デバイスへの保存がプレーンテキストの状態で行われないようにします。 極めて機密性の高いデータについては、カット & ペースト用バッファーを無効にし、アプリ外へ漏れないようにします。 アプリをそのデータストアと通信チャネルも含めて動的にテストし、不適切に送信されたり保存されたりする機密データがないことを確認します。

暗号化処理の間違った使い方 (M9)

ソフトウェアの暗号の脆弱性は、そのほとんどが鍵の不適切な管理に原因がありますが、暗号システムのあらゆる側面を慎重に設計し、実装する必要があります。この点において、モバイルアプリも違いはありません。

対策

暗号鍵を、攻撃者が簡単に復元できるような場所に "ハードコーディング" したり保存したりすることは絶対にしないでください。これには、プレーンテキストデータファイル、プロパティファイル、コンパイル済みバイナリなどが含まれます。 暗号鍵の保存にはセキュアなコンテナーを使用します。または、鍵が安全なサーバーによって管理され、鍵がモバイルデバイス上にローカルに保存されることは絶対にない安全な鍵交換システムを構築します。 鍵生成ツールやハッシュなど、強力な暗号アルゴリズムや実装だけを使用してください。可能であれば、プラットフォームの暗号 API を使用します。それができない場合は、信頼できるサードパーティのコードを使用します。 個人ユーザーレベルの機密データは、Apple が提供する API を使用して安全なコンテナーに保存します。

  • ユーザー認証の資格情報やセッショントークンなど、少量のデータは、デバイスのキーチェーンに安全に保存できます (Apple の「iOS Developer Library」の「Keychain Services Reference」を参照)。
  • これより大きいか、より一般的な種類のデータには、Apple のファイル保護メカニズムを安全に使用できます (保護オプションについては「NSData Class Reference」を参照)。

より安全に静的データを保護するには、Apple の暗号化に固有の脆弱性に煩わされることのないサードパーティの暗号化 API の使用を検討してください (例: ユーザーのデバイスパスコードに紐付けられた入力。通常は 4 桁の PIN)。例えば無償で提供されている SQLcipher (http://sqlcipher.net を参照) などがあります。

機密情報の漏えい (M10)

あらゆる種類の機密データが iOS アプリから漏えいする危険があります。これ以外に常に念頭に置いておくべきことは、各アプリのコンパイル済みバイナリコードはデバイス上にあり、リバースエンジニアリングされるおそれがある、ということです。

対策

完全に非公開にしておく必要のあるものは、モバイルデバイス上に置いてはいけません。非公開とすべき情報 (アルゴリズム、機密情報など) はサーバーに保持してください。 非公開情報がどうしてもモバイルデバイス上に必要な場合は、非公開情報をプロセスメモリにとどめておき、非公開情報をデバイスに保存する必要があるときは、絶対に無防備な状態にさらさないでください。 パスワード、セッショントークンなどをハードコーディングしたり、安易に保存したりすることは絶対にしないでください。 プログラムバイナリは、出荷する前にストリップ処理を行ってください。コンパイル済み実行形式ファイルの中身は、リバースエンジニアリングによって分析することが可能です。

参考資料

「OWASP Top 10 Mobile Risks」プレゼンテーション、Appsec USA、ミネソタ州ミネアポリス、2011 年 9 月 23 日、Jack Mannino、Mike Zusman、Zach Lanier

「iOS Security」、Apple、2014 年 11 月、https://www.apple.com/business/docs/iOS_Security_Guide_Oct_2014.pdf

「Deploying iPhone and iPad: Apple Configurator」Apple、2012 年 3 月、http://images.apple.com/iphone/business/docs/iOS_Apple_Configurator_Mar12.pdf

「iPhone OS: Enterprise Deployment Guide」、Apple、2010 年 http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf

「iPhone in Business」、Apple リソース、http://www.apple.com/iphone/business/resources/

Apple iOS 開発者向け Web サイト

「iOS Application (in)Security」、MDSec - 2012 年 5 月、http://www.mdsec.co.uk/research/iOS_Application_Insecurity_wp_v1.0_final.pdf

Authors and Primary Editors

Ken van Wyk ken[at]krvw.com

Contributors:Jason.Haddix@hp.com

Other Cheatsheets

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets