セキュアなモバイル開発方法の理解

サーバー側の不十分な制御

データを保管するバックエンド・サービスへの攻撃に対して脆弱になるモバイル・アプリケーションには、モバイル・デバイスで実行するクライアント・アプリケーションではなく、サーバー側のアプリケーションを使用してアクセス制御を強制実施します。

モバイル・アプリケーションにセキュリティを組み込みます。モバイル・アプリケーションの設計における最も初期の段階でも、モバイル・アプリケーションに固有のリスクだけでなく、モバイル・アプリケーションがアクセスするサーバー側リソースに共通するリスクも評価する必要があります。同等のデスクトップ・アプリケーションと同様に、モバイル・アプリケーションは、データを格納するバックエンド・サービスへの攻撃によって脆弱になる可能性があります。このリスクはモバイル・アプリケーションに固有のものではないため、「OWASP Top Ten Project」(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)に示されている基準は、モバイル・アプリケーションの作成時にも当てはまります。モバイル・デバイスで実行されているクライアント・アプリケーションは脆弱である可能性があるため、これらを使用してアクセス制御を適用しないでください。この機能はサーバー側アプリケーションによって実行される必要があるため、MAFは、クライアントから送信されるデータを検証するための即時利用可能な機能は提供していません。モバイル・アプリケーションに送信されるデータが有効であることを確認する必要があります。次を参照してください。

『Oracle Web Services Managerの理解』のWebサービスのセキュリティ概念の理解に関する項
『Oracle Web Services Managerの理解』のWebサービス・セキュリティ標準に関する項

デバイス上のセキュアでないデータ格納

モバイル・アプリケーションの設計では、ユーザーがローカル・ファイルにアクセスできるようにすることがあり、その結果としてデバイスのローカル・ファイル・システムに保管された機密データを公開することになります。MAFには、デバイス・データベースとローカル・データを暗号化して、デバイスにデータを安全に保管するAPIが用意されています。

モバイル・アプリケーションの設計に欠陥があると、ユーザーがローカル・ファイルにアクセスできるようになり、デバイスのローカル・ファイル・システムに保管された機密データが公開されてしまうことになります。このデータには、ユーザー名とパスワード、Cookie、認証トークンなどがあります。ほとんどのユーザーは自分のデータが脆弱であること、さらにはデバイス自体に格納されていることを認識していませんが、悪意のあるユーザーがツールを使用してローカル・データベースを開き、資格証明を表示することで、この状況を利用する可能性があります。アプリケーションのセキュリティ要件を評価するときは、電話が悪者の手に渡る可能性を想定する必要があります。MAFは、デバイス・データベースおよびローカル・データ・ストアを暗号化することによってデバイスに格納されたデータを保護するAPIを提供しています。

SQLiteデータベースの暗号化

MAFの埋込みSQLiteデータベースは、ローカルに格納されたデータを保護します。MAFアプリケーションは、SQLiteデータバースを共有しません。データベースにアクセスできるアプリケーションは、データベースを作成するアプリケーションのみです。さらに、このデータベースには、正しいユーザー名とパスワードを持つユーザーのみがアクセスできます。

AdfmfJavaUtilitiesクラスを使用すると、このデータベースのパスワードを保護するキーを作成するとともに、データベース内に格納されたデータを暗号化することができます。データベースに安全なキーを提供するために、AdfmfJavaUtilitiesクラスには、強力なパスワードを生成してから安全に格納するGeneratedPasswordユーティリティ・クラスが含まれます。また、AdfmfJavaUtilitiesクラスは、パスワードを使用してデータベースを暗号化するためのencryptDatabaseメソッドも提供します。SQLiteデータベースの一般的な情報は、「MAF AMXでのローカル・データベースの使用方法」を参照してください。GeneratedPasswordおよびencryptDatabase (およびその対となるdecryptDatabase)の詳細は、Oracle Mobile Application Framework Java APIリファレンスおよび「データベースを暗号化および復号化する方法」を参照してください。サンプル・アプリケーションは、「サンプルのMAFアプリケーション」の説明に従って、PublicSamples.zip内のStockTrackerのサンプルを参照してください。

注意:

必ずGeneratedPasswordユーティリティを使用してください。キーをハードコード化しないでください。

デバイスのローカル・データ・ストアの保護

adfmfJavaUtiltiesクラスのgetDirectoryPathRootメソッドを使用して、MAFがサポートするプラットフォームで、プログラムによってファイルをローカル・ファイル・システムに保管できます。このメソッドを使用すると、デバイスでのアプリケーション・データの格納に対して、プラットフォームに依存しないアクセスが可能になります。

このメソッドには、次のオプションを使用できます。

一時ディレクトリ
アプリケーション・ディレクトリ
キャッシュ・ディレクトリ
ダウンロード・ディレクトリ

ヒント:

ユーザーがデスクトップ・コンピュータとデバイスを同期するときには、デバイスのアプリケーション・ディレクトリに格納されているデータがデスクトップ・システムに転送されますが、ここでデータが公開される可能性があります。データを一時ディレクトリに格納してください。iOSでは、iTunesを使用してデバイスが同期されるときに、一時ディレクトリに格納されたデータはデスクトップと同期されません。

セキュリティを必要とするすべてのファイルに対して、Java暗号化API (javax.crypto)を使用して暗号化および復号化を行うことができます。

getDirectoryPathRootメソッドの詳細は、「getDirectoryPathRootメソッドを使用したファイル・アクセス」を参照してください。また、iOSのDeveloper Library (https://developer.apple.com/library/)で参照できる、『File System Programming Guide』の「File System Basics」も参照してください。

セキュリティ・ログとアプリケーション・ログについて

デスクトップ・コンピュータと同期されたデバイスは、ログ・ファイルを表示します。機密データがログ・ファイルに書き込まれないようにしてください。

デスクトップ・コンピュータと同期された場合に表示できるので、いずれの機密データもログ・ファイルに書込みできないことを確認してください。ユーザーがiOSデバイスをデスクトップ・システムに接続してデータを同期すると、アプリケーション・ログ・ファイルは最終的に、暗号化されていない形式でデスクトップ上に格納されます。Androidデバイスから同期されたログ・ファイルは、Android Device Monitorツールを使用して表示できます。「サイドチャネルによるデータ漏えい」も参照してください。

トランスポート・レイヤーの不十分な保護

モバイル・アプリケーションは、プロバイダ・ネットワークを介してデータにアクセスするときにSSL/TLSを使用し、WiFiを使用する場合はこれらのどちらのプロトコルも使用しないことがあります。プロバイダ・ネットワークはハッキングされる可能性があるため、安全であることを想定しないようにしてください。

したがって、アプリケーションが機密データをトランスポートするときはSSLを強制し、すべての証明書が有効で公的機関によって署名されていることを確認する必要があります。

モバイル・アプリケーションによって使用されるすべてのエンドポイントはSSLによって保護される必要があるため、MAFは、SSLをサポートする一連のWebサービス・ポリシーを提供します。「セキュアなWebサービスへのアクセス」を参照してください。

MAFは、信頼性のある既知の認証局のエントリによってシードされたcacertsファイルを提供します。アプリケーション開発者は、必要に応じてこのファイルに他の証明書を追加できます。「SSLのサポート」を参照してください。

サイドチャネルによるデータ漏えい

スクリーン・ショット、キー・ストローク・ロギング、デバッグ・メッセージ、クリップボード・コピーとOpen In機能、一時ディレクトリおよびサード・パーティ製ライブラリはデータ漏えいの原因になることがあります。資格証明や個人を特定できる情報はロギングしないでください。また、アプリケーションの公開前に、デバッグ時のファイルを確認してデバッグメッセージを削除することで、データ漏えいを防止できます。

意図しないデータ漏えいは、次のような原因で発生する可能性があります。

スクリーン・ショットの無効化(バックグラウンド実行): iOSおよびAndroidは、アプリケーションの再アクティブ化の認識されるパフォーマンスを高めるために、アプリケーションをバックグラウンドで実行する前にアプリケーションのスクリーン・ショットを取得します。しかし、顧客データの漏えいの可能性があるため、これらのスクリーン・ショットはセキュリティ上の問題の原因となります。
キー・ストローク・ロギング: iOSおよびAndroidでは、キーボードを使用して入力した情報の一部が、先行入力機能で使用するためにアプリケーション・ディレクトリに自動的に記録されます。この機能は、顧客データの潜在的な漏えいにつながる可能性があります。
デバッグ・メッセージ: アプリケーションでは、機密データをデバッグ・ログに書き込むことができます。ロギング・レベルを「FINE」に設定すると、ユーザーのデバイスとサーバーの間で転送されるすべてのデータに関してログ・メッセージが書き込まれます。
アプリケーションの一部として表示される機密ドキュメントに関して、クリップボード・コピーおよび「Open In」機能を無効にします。MAFでは現在、コピーおよびOpen In機能を無効にする機能は提供されておらず、今後のリリースで提供が予定されています。
一時ディレクトリ: 機密データが含まれる場合があります。
サード・パーティ・ライブラリ: これらのライブラリ(adライブラリなど)により、ユーザー、デバイス、ユーザーの場所に関するユーザー情報が漏えいする可能性があります。

データ漏えいを防止するには:

資格証明、個人情報(PII)などの機密データをアプリケーション・ログに記録しないようにします。すべての機密情報をネイティブ・キー・チェーン、暗号化データベースまたはファイル・システムに格納します。
アプリケーションのデバッグ時に、作成されたすべてのファイルおよびそれらのファイルに書き込まれたすべての内容を確認します。
アプリケーションを公開する前に、デバッグ・メッセージを削除します。

脆弱な認可および認証

脆弱な認証メカニズムとクライアント側アクセス制御はセキュリティを損ないます。安全なアクセスを必要とするMAFアプリケーションの機能は、それをサーバー側で強制実施する必要があります。

エンド・ユーザーはユーザー名とパスワードよりも、電話番号またはなんらかのタイプの識別子(IMEI、IMSIまたはUUID)を使用してデバイスを認証する方が簡単ですが、これらの識別子は総当たり攻撃によって容易に検出される可能性があるため、唯一のオーセンティケータとして使用しないようにしてください。かわりにモバイル・アプリケーションは、機密データにアクセスするときは強力な資格証明を使用する必要があります。認証は、デバイスではなくユーザーを反映する必要があります。さらに、コンテキスト識別子(場所など)、音声、フィンガープリントまたは動作情報を使用して認証を強化できます。

開発者は、MAFで提供されているデフォルトのログイン・ページまたは開発者が作成するカスタム・ログイン・ページのいずれかを使用できます。「ログイン・ページの指定方法」を参照してください。

安全なアクセスを必要とするMAFアプリケーションのすべての機能は、「認証を要求するようにアプリケーション機能を設定する方法」の説明に従ってセキュリティを有効にする必要があります。

さらに、クライアントではなくサーバーによってアクセス制御を強制する必要があります。クライアント・モバイル・アプリケーションがこの機能を担うと、安全性が低下します。アクセス制御サービス(ACS)を使用すると、開発者は、サーバー上で定義されたロール/権限を使用してモバイル・アプリケーションでアクセス制御を強制することができます。アクセス制御サービスは、アプリケーションで有効なユーザー・ロール/権限をフィルタリングするためにアプリケーション開発者が実装できる、RESTfulサービスです。アプリケーションでは数千のユーザー・ロールがサポートされている場合がありますが、このサービスは、モバイル・アプリケーションに対して指定したロールのみを返します。「アクセス制御の構成方法」を参照してください。

不適切な暗号化

暗号化は、間違った実装と不適切なアルゴリズムの使用によって脆弱になります。暗号化されたデータとは別にキーを保管して、プラットフォーム固有のファイル暗号化APIを使用するか、その他の正常な暗号化が保証される信頼できるソースを使用します。

次の理由により、暗号化は不確実なものになります。

アプリケーションで間違った実装を使用しているか、または既知のアルゴリズムを不正に使用している。
暗号が容易に解読されるために、データが安全でない。

さらに、Base-64エンコーディング、不明瞭化およびシリアライズは暗号化ではありません(暗号化と誤解しないようにしてください)。

データを正常に暗号化するには:

暗号化データと一緒にキーを格納しないでください。
プラットフォーム固有のファイル暗号化APIまたは別の信頼できるソースを使用します。暗号を自分で作成しないでください。

埋込みSQLiteデータベースのセキュリティ保護に加え、「デバイス上のセキュアでないデータ格納」で説明されている暗号化メソッドを使用します。また、「トランスポート・レイヤーの不十分な保護」で説明されているように、SSLを適用してセキュリティで保護されたWebサービス・コールを作成します。MAFでは、資格証明をセキュアに処理するため、Oracle Access Manager for MobileおよびSocial IDM SDKを使用します。

クロスサイト・スクリプティングのクライアント側インジェクション

MAFエンコーディングは、クロスサイト・スクリプティング・インジェクションからアプリケーションを保護し、アプリケーションのサンドボックス化は、クロスサイト・リクエスト・フォージェリに対する保護を提供します。アプリケーション機能のアクセスを無効化することで、ネイティブ・コンテナもアプリケーションの安全を確保できます。

モバイル・アプリケーションは様々なソースからコンテンツおよびデータを取り出すため、ユーザー・セッションを乗っ取るクロスサイト・スクリプティング(XSS)インジェクションに対して脆弱である可能性があります。MAFでは、エンコーディングによりXSSに対する保護を行います。

インジェクション攻撃に加えて、モバイル・アプリケーションはクロスサイト・リクエスト・フォージェリ(CSRF)に対して脆弱であり、この攻撃では、悪意のあるページが、ユーザーIDを格納するWebブラウザにキャッシュされたCookieを使用して、ユーザーに代わってターゲット・アプリケーションで意図しないアクションを実行します。アプリケーションのサンドボックス化により、CSRFの問題に対処します。

また、ネイティブ・コンテナにアクセスするアプリケーション機能(特にリモートURLコンテンツに関わるアプリケーション機能)を無効にすることを検討してください。MAFアプリケーション内の選択したアプリケーション機能がネイティブ・コンテナにアクセスすることを防止できます。たとえば、自分のMAFアプリケーションに、リモート・コンテンツを参照する、信頼できないWebアプリケーションからのアプリケーション機能が含まれているとします(リモートURLコンテンツのアプリケーション機能)。このシナリオでは、次の例に示すように、この特定のアプリケーション機能がネイティブ・コンテナにアクセスすることを防止します。

<adfmf:featureReference refId="remoteAppfeature1" id="fr1" allowNativeAccess="false"/>

allowNativeAccessプロパティのデフォルト値はtrueです。

デバイス・アクセス権限を使用したインジェクション攻撃からのMAFアプリケーションの保護

MAFアプリケーションは、デバイスの機能(電話や電子メール)へのURIアクセスが制限されるように構成することで保護します。

URIは、ユーザーのデバイスに格納されたデータの他、カメラやアドレス帳などの様々なデバイス機能にアクセスできます。「MAFアプリケーションでのコア・プラグインの有効化」で説明されているように、このようなアクセス権はデフォルトでは付与されていませんが、MAFアプリケーションを構成して、URIがアクセスできるデバイスの機能を、次のいずれかに制限できます。

オープン・ネットワーク・ソケット(ユーザー認証の構成時に許可する必要がある)
GPSおよびネットワークベースの位置情報サービス
連絡先
電子メール
SMS
電話
プッシュ通知
ローカルに格納されたファイル

ヒント:

「実行時の名前付き接続の接続属性の更新方法」で説明されているように、updateSecurityConfigWithURLParametersメソッド(ログイン構成の変更を検出すると、再認証によって変更を確認するようにユーザーに求める)を使用して、XSSによって挿入された偽のログイン・ページなどのセキュリティ・リスクから、プログラムによってユーザーを保護できます。さらに、MAFでは、保護されたアプリケーション機能を開くときに、それがユーザーに通知されます。デフォルト・アプリケーションにセキュリティが適用されないと、認証が遅延する可能性があります。Oracle Mobile Application Framework Java APIリファレンスを参照してください。

カスタムHTMLコンポーネントからのインジェクション攻撃リスクについて

MAF AMXページにカスタム・ユーザー・インタフェースを作成するために、ELバインディングによって動的HTMLコンテンツを配信するHTMLを使用すると、アプリケーションにインジェクション攻撃の余地を残す可能性があります。HTMLとJavaScriptスクリプトは、機能を保護するために適切にエンコードする必要があります。

HTMLを使用してMAF AMXページでカスタム・ユーザー・インタフェース・コンポーネントを作成すると、アプリケーションがインジェクション攻撃を受けやすい状態になる可能性があります。MAFは、MAF AMXページのHTMLコンテンツに対して、<amx:verbatim>と<amx:outputHTML>の2つのコンポーネントを提供しています。<amx:verbatim>コンポーネントでは動的HTMLが許可されないため、インジェクション攻撃を受けにくくなります。ただし、ELバインディングによって動的HTMLコンテンツを配信する<amx:outputHTML>コンポーネントは、そのsecurity属性をnoneに構成すると脆弱になる可能性があります。デフォルトでは、onClickイベントなど、フレームワークが様々なHTMLタグをエスケープしてJavaScriptを削除できるように、この属性はhighに設定されています。この属性をnoneに設定すると、iFrameコンポーネントおよびJavaScriptが有効になる(これにより、AMXベージ内でAJAXリクエストが可能になる)ため、HTMLおよびJavaScriptが適切にエンコードされていることを確認する必要があります。「Verbatimコンポーネントの使用方法」および「出力HTMLコンポーネントの使用方法」を参照してください。また、「信頼できない入力のセキュリティ判断」も参照してください。

SQLインジェクションおよびXMLインジェクションについて

ローカル・データベースに保管されたすべてのデータを検証してエンコードすることと、アプリケーションで処理されるXMLおよびHTMLコンテンツをエンコードして検証することで、SQLインジェクションを防止できます。

モバイル・アプリケーションはSQLインジェクションに対して脆弱であるため、攻撃者は埋込みSQLiteデータベースに格納されたデータを読取りできる可能性があります。

SQLインジェクションを防止するには:

アプリケーション開発者は、ローカル・データベースに格納されたすべてのデータを検証し、エンコードする必要があります。
アプリケーション開発者は、アプリケーションによって処理されるXMLおよびHTMLコンテンツをエンコードし、検証することが想定されています。

信頼できない入力のセキュリティ判断

追加の認証を求めること、機密性の高いアプリケーションを起動する際の追加の手順を用意すること、サーバー上の信頼できないサード・パーティ製アプリケーションとの通信をすべて検証すること、およびJSONエンコーディングAPIを使用することで、iOSとAndroidのプラットフォーム上のアプリケーションの安全を確保できます。

iOSプラットフォームとAndroidプラットフォームの両方において、アプリケーション(Skypeなど)は必ずしも外部からの許可をリクエストするとは限らないため、攻撃者にエントリ・ポイントを提供して、悪意のあるアプリケーションがセキュリティを回避してしまう可能性があります。その結果、アプリケーションはクライアント側のインジェクションおよびデータ漏えいに対して脆弱になります。必ず追加の認可を求めるプロンプトを表示するか、あるいは追加の認可が可能でない場合は、保護を必要とするアプリケーションを起動するための追加のステップを提供してください。

アプリケーションが信頼できないサードパーティ・アプリケーションから受信する(またはこれらのアプリケーションに送信する)すべてのデータが、入力検証の対象となっていることを確認する必要があります。アプリケーションに対するクライアント側のXML入力を、エンコードおよび検証する必要があります。MAF AMXコンポーネントではユーザー入力を検証できますが、データはサーバー上で検証する必要があり、サーバーはクライアントから受信するデータを信頼しないようにする必要があります。つまり、サーバーとクライアントの間で送受信されるXML、JSONおよびJavaScriptが適切にエンコードされていることを確認する役割は、サーバーが担います。

別のアプリケーションからMAFアプリケーションを起動するURLスキームを構成するときは、URLを介して送信されるパラメータを検証して、悪意のあるデータまたはURIがMAFアプリケーションに渡される可能性がないことを確認する必要があります。「カスタムURLスキームを使用したMAFアプリケーションの起動」および「脆弱なサーバー側コントロール」を参照してください。

JSON解析について

可能な場合は、MAFのJSONエンコーディングAPIを使用します。カスタムJSON構成を必要とするシナリオでは、ユーザー入力データを使用してJSONを構成するときには注意が必要です。JSONデータの処理の詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。

不適切なセッション処理

セッション・タイムアウトの値をサーバー側のセッション・タイムアウトよりも小さく構成すること、有効期限が構成された複雑なトークンを使用すること、および機能セッションの時間値とユーザーに再認証を強制するタイムアウトを構成することは、セッション処理のベスト・プラクティスとしてあげられます。

モバイル・アプリケーションのユーザビリティ要件では、多くの場合、長期にわたって継続するセッションが求められます。モバイル・アプリケーションは、セッション管理にCookie、SSOサービスおよびOAUTHトークンを使用します。

注意:

OAuthアクセス・トークンは、リモートで取り消すことができます。

適切なセッション処理を有効にするには:

ログイン・サーバー接続のセッション・タイムアウトを、サーバー側のセッション・タイムアウトよりも小さい値に構成します。

デバイスIDは期限切れになることがないため、セッション・トークンとして使用しないでください。アプリケーションでは、ユーザーが再認証を行う必要が生じても、トークンを期限切れにする必要があります。
サーバーでのトークン生成の適切なベスト・プラクティス(OWASP Top 10プロジェクト: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projectを参照)を確認してください。

容易に予測できるか、または適切に生成されていないセッション・トークンを使用しないでください。セッション・トークンは予測不能で、エントロピが高い必要があります。

Oracle Identity Management (IDM)スタックでは、モバイル・アプリケーションで使用するための標準ベースのトークン(OAuthアクセス・トークン、JWTトークンなど)がサポートされています。MAFでは、Oracle IDM OAuthサーバーに対して即時利用可能なサポートが提供されており、MAFアプリケーションでこのような標準ベースの認証メカニズムを使用することをお薦めします。

「基本認証の構成方法」で説明されているように、ユーザーがログイン・サーバーに対して認証を行う必要があるアプリケーションの構成には、セッションの持続時間およびアイドル・タイムアウトを設定するオプションが含まれます。デフォルトでは、アプリケーション機能セッションの持続時間は8時間です。アプリケーション機能がアイドル状態にあるデフォルト時間は、5分間です。MAFでは、いずれかの構成期間が過ぎるとユーザー資格証明が期限切れになり、ユーザーに再認証を求めるプロンプトが表示されます。

バイナリ保護の欠如による機密情報の開示

APIキーと機密ビジネス・ロジックをサーバーに保管すること、パスワードをハードコーディングしないこと、機密情報をログ・ファイルに書き込まないことで、データ(APIキー、パスワード、機密ビジネス・ロジックなど)を保護します。

攻撃者はリバース・エンジニアリングを使用して、APIキー、パスワード、機密ビジネス・ロジックなどの機密データを検出できます。この情報を保護するには:

APIキーおよび機密ビジネス・ロジックをサーバー上に格納します。
パスワードをアプリケーション・バイナリに格納しないでください。
パスワードをハードコード化しないでください。かわりに、「デバイス上のセキュアでないデータ格納」で説明されているGeneratedPasswordユーティリティを使用します。
ログ・ファイルをモニターできるので、アプリケーションが機密情報をログ・ファイルに書き込まないことを確認します。「サイドチャネルによるデータ漏えい」も参照してください。
情報がファイル・システム上に格納される(つまり、モバイル・アプリケーションの外部に格納される)ことに注意してください。機密データを暗号化されたデータベースまたはファイル・システム、あるいはネイティブ・キー・チェーンに格納します。リスク1:「デバイスでの安全でないデータ格納」も参照してください。