| Oracle Enterprise Pack for Eclipse Oracle Mobile Application Framework (OEPE Edition)でのモバイル・アプリケーションの開発 リリース2.2.1 E72511-01 |
|
 前 |
 次 |
| Oracle Enterprise Pack for Eclipse Oracle Mobile Application Framework (OEPE Edition)でのモバイル・アプリケーションの開発 リリース2.2.1 E72511-01 |
|
前 |
次 |
モバイル・アプリケーション・フレームワークは、次の項で説明する、Open Web Application Security Project (OWASP)によって特定される一般的なセキュリティ上のリスクからの保護を実現します。
モバイル・アプリケーションにセキュリティを組み込みます。モバイル・アプリケーションの設計における最も初期の段階でも、モバイル・アプリケーションに固有のリスクだけでなく、モバイル・アプリケーションがアクセスするサーバー側リソースに共通するリスクも評価する必要があります。同等のデスクトップ・アプリケーションと同様に、モバイル・アプリケーションは、データを格納するバックエンド・サービスへの攻撃によって脆弱になる可能性があります。このリスクはモバイル・アプリケーションに固有のものではないため、「OWASP Top Ten Project」(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)に示されている基準は、モバイル・アプリケーションの作成時にも当てはまります。モバイル・デバイスで実行されているクライアント・アプリケーションは脆弱である可能性があるため、これらを使用してアクセス制御を適用しないでください。この機能はサーバー側アプリケーションによって実行される必要があるため、MAFは、クライアントから送信されるデータを検証するための即時利用可能な機能は提供していません。モバイル・アプリケーションに送信されるデータが有効であることを確認する必要があります。詳細は、次を参照してください。
Oracle Fusion Middleware Oracle Web Services Managerの理解にある、「Webサービスのセキュリティ概念の理解」
Oracle Fusion Middleware Oracle Web Services Managerの理解にある、「Webサービスのセキュリティ標準」
Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護
モバイル・アプリケーションの設計に欠陥があれば、ローカル・ファイルがユーザーからアクセス可能となり、デバイスのローカル・ファイル・システムに格納された機密データが公開されてしまう可能性があります。このデータには、ユーザー名とパスワード、Cookie、認証トークンなどがあります。ほとんどのユーザーは自分のデータが脆弱であること、さらにはデバイス自体に格納されていることを認識していませんが、悪意のあるユーザーがツールを使用してローカル・データベースを開き、資格証明を表示することで、この状況を利用する可能性があります。アプリケーションのセキュリティ要件を評価するときは、電話が悪者の手に渡る可能性を想定する必要があります。MAFは、デバイス・データベースおよびローカル・データ・ストアを暗号化することによってデバイスに格納されたデータを保護するAPIを提供しています。
MAFの埋込みSQLiteデータベースは、ローカルに格納されたデータを保護します。MAFアプリケーションは、SQLiteデータバースを共有しません。データベースにアクセスできるアプリケーションは、データベースを作成するアプリケーションのみです。さらに、このデータベースには、正しいユーザー名とパスワードを持つユーザーのみがアクセスできます。AdfmfJavaUtilitiesクラスを使用すると、このデータベースのパスワードを保護するキーを作成するとともに、データベース内に格納されたデータを暗号化することができます。データベースに安全なキーを提供するために、AdfmfJavaUtilitiesクラスには、強力なパスワードを生成してから安全に格納するGeneratedPasswordユーティリティ・クラスが含まれます。また、AdfmfJavaUtilitiesクラスは、パスワードを使用してデータベースを暗号化するためのencryptDatabaseメソッドも提供します。SQLiteデータベースの一般的な情報は、第20章「MAF AMXでのローカル・データベースの使用方法」を参照してください。GeneratedPassword、encryptDatabase (およびこれに対応するdecryptDatabase)の詳細は、Oracle Mobile Application Framework Java APIリファレンスおよび第20.2.7項「データベースを暗号化および復号化する方法」を参照してください。サンプル・アプリケーションについては、PublicSamples.zipのStockTrackerサンプルを参照してください(付録G「サンプルのMAFアプリケーション」を参照)。
|
注意: 必ずGeneratedPasswordユーティリティを使用してください。キーをハードコード化しないでください。 |
adfmfJavaUtiltiesクラスのgetDirectoryPathRootメソッドを使用して、iOSプラットフォームとAndroidプラットフォームの両方で、プログラムによりファイルをローカル・ファイル・システムに格納できます。このメソッドを使用すると、デバイスでのアプリケーション・データの格納に対して、プラットフォームに依存しないアクセスが可能になります。このメソッドには、次のオプションを使用できます。
一時ディレクトリ
アプリケーション・ディレクトリ
キャッシュ・ディレクトリ
ダウンロード・ディレクトリ
|
ヒント: ユーザーがデバイスをデスクトップ・コンピュータに同期すると、デバイスのアプリケーション・ディレクトリに格納されたデータが、そのデータを公開できるデスクトップ・システムに転送されます。データを一時ディレクトリに格納してください。iOSでは、iTunesを使用してデバイスが同期されるときに、一時ディレクトリに格納されたデータはデスクトップと同期されません。 |
セキュリティを必要とするすべてのファイルに対して、Java暗号化API (javax.crypto)を使用して暗号化および復号化を行うことができます。javax.cryptoパッケージの詳細は、Java Platform, Standard Edition 1.4 APIを参照してください。詳細は、Oracle Mobile Application Framework Java APIリファレンスおよび第B.3項「getDirectoryPathRootメソッドを使用したファイル・アクセス」を参照してください。iOS Developer Library (https://developer.apple.com/library/)にある『File System Programming Guide』の「File System Basics」も参照してください。
デスクトップ・コンピュータと同期された場合に表示できるので、いずれの機密データもログ・ファイルに書込みできないことを確認してください。ユーザーがiOSデバイスをデスクトップ・システムに接続してデータを同期すると、アプリケーション・ログ・ファイルは最終的に、暗号化されていない形式でデスクトップ上に格納されます。Androidデバイスから同期されたログ・ファイルは、Android Device Monitorツールを使用して表示できます。第29.4項「サイドチャネルによるデータ漏えい」も参照してください。
モバイル・アプリケーションは、プロバイダ・ネットワークを介してデータにアクセスするときにSSL/TLSを使用し、WiFiを使用する場合はこれらのどちらのプロトコルも使用しないことがあります。プロバイダ・ネットワークはハッキングされる可能性があるため、安全であることを想定しないようにしてください。したがって、アプリケーションが機密データをトランスポートするときはSSLを強制し、すべての証明書が有効で公的機関によって署名されていることを確認する必要があります。
モバイル・アプリケーションによって使用されるすべてのエンドポイントはSSLによって保護される必要があるため、MAFは、SSLをサポートする一連のWebサービス・ポリシーを提供します。SOAP WebサービスまたはREST Webサービスのいずれかに関連付けることができるポリシーのリストは、第15.6項「セキュアなWebサービスへのアクセス」を参照してください。
MAFは、信頼性のある既知の認証局のエントリによってシードされたcacertsファイルを提供します。アプリケーション開発者は、必要に応じてこのファイルに他の証明書を追加できます。詳細は、第30.9項「SSLのサポート」を参照してください。
意図しないデータ漏えいは、次のような原因で発生する可能性があります。
スクリーン・ショットの無効化(バックグラウンド実行): iOSおよびAndroidは、アプリケーションの再アクティブ化の認識されるパフォーマンスを高めるために、アプリケーションをバックグラウンドで実行する前にアプリケーションのスクリーン・ショットを取得します。しかし、顧客データの漏えいの可能性があるため、これらのスクリーン・ショットはセキュリティ上の問題の原因となります。
キー・ストローク・ロギング: iOSおよびAndroidでは、キーボードを使用して入力した情報の一部が、先行入力機能で使用するためにアプリケーション・ディレクトリに自動的に記録されます。この機能は、顧客データの潜在的な漏えいにつながる可能性があります。
デバッグ・メッセージ: アプリケーションでは、機密データをデバッグ・ログに書き込むことができます。ロギング・レベルを「FINE」に設定すると、ユーザーのデバイスとサーバーの間で転送されるすべてのデータに関してログ・メッセージが書き込まれます。
アプリケーションの一部として表示される機密ドキュメントに関して、クリップボード・コピーおよび「Open In」機能を無効にします。MAFでは現在、コピーおよびOpen In機能を無効にする機能は提供されておらず、今後のリリースで提供が予定されています。
一時ディレクトリ: 機密データが含まれる場合があります。
サード・パーティ・ライブラリ: これらのライブラリ(adライブラリなど)により、ユーザー、デバイス、ユーザーの場所に関するユーザー情報が漏えいする可能性があります。
データ漏えいを防止するには:
資格証明、個人情報(PII)などの機密データをアプリケーション・ログに記録しないようにします。すべての機密情報をネイティブ・キー・チェーン、暗号化データベースまたはファイル・システムに格納します。
アプリケーションのデバッグ時に、作成されたすべてのファイルおよびそれらのファイルに書き込まれたすべての内容を確認します。
アプリケーションを公開する前に、デバッグ・メッセージを削除します。
不十分な認証メカニズムとクライアント側アクセス制御は両方とも、セキュリティを脅かします。
エンド・ユーザーはユーザー名とパスワードよりも、電話番号またはなんらかのタイプの識別子(IMEI、IMSIまたはUUID)を使用してデバイスを認証する方が簡単ですが、これらの識別子は総当たり攻撃によって容易に検出される可能性があるため、唯一のオーセンティケータとして使用しないようにしてください。かわりにモバイル・アプリケーションは、機密データにアクセスするときは強力な資格証明を使用する必要があります。認証は、デバイスではなくユーザーを反映する必要があります。さらに、コンテキスト識別子(場所など)、音声、フィンガープリントまたは動作情報を使用して認証を強化できます。
開発者は、MAFで提供されているデフォルトのログイン・ページまたは開発者が作成するカスタム・ログイン・ページのいずれかを使用できます。詳細は、第30.6.2項「ログイン・ページの指定方法」を参照してください。
第30.6.1項「認証を要求するようにアプリケーション機能を設定する方法」で説明されているように、安全なアクセスを必要とするMAFアプリケーションのすべての機能は、セキュリティを有効にする必要があります。
さらに、クライアントではなくサーバーによってアクセス制御を強制する必要があります。クライアント・モバイル・アプリケーションがこの機能を担うと、安全性が低下します。アクセス制御サービス(ACS)を使用すると、開発者は、サーバー上で定義されたロール/権限を使用してモバイル・アプリケーションでアクセス制御を強制することができます。アクセス制御サービスは、アプリケーションで有効なユーザー・ロール/権限をフィルタリングするためにアプリケーション開発者が実装できる、RESTfulサービスです。アプリケーションでは数千のユーザー・ロールがサポートされている場合がありますが、このサービスは、モバイル・アプリケーションに対して指定したロールのみを返します。詳細は、第30.5.18項「アクセス制御の構成方法」を参照してください。
次の理由により、暗号化は不確実なものになります。
アプリケーションで間違った実装を使用しているか、または既知のアルゴリズムを不正に使用している。
暗号が容易に解読されるために、データが安全でない。
さらに、Base-64エンコーディング、不明瞭化およびシリアライズは暗号化ではありません(暗号化と誤解しないようにしてください)。
データを正常に暗号化するには:
暗号化データと一緒にキーを格納しないでください。
プラットフォーム固有のファイル暗号化APIまたは別の信頼できるソースを使用します。暗号を自分で作成しないでください。
第29.2項「デバイスでの安全でないデータ格納」に示す暗号化方法を使用して、埋込みSQLiteデータベースを保護するのに加えて、SSLを適用して安全なWebサービス・コールを作成します(第29.3項「不十分なトランスポート・レイヤー保護」を参照)。MAFは資格証明を安全に処理するために、Mobile and Social IDM SDK用にOracle Access Managerを使用します。
モバイル・アプリケーションは様々なソースからコンテンツおよびデータを取り出すため、ユーザー・セッションを乗っ取るクロスサイト・スクリプティング(XSS)インジェクションに対して脆弱である可能性があります。MAFは主にエンコーディングによってXSSを防止しますが、追加の安全策としてホワイトリストを使用します。
ホワイトリストは、許可されたドメインのみがアプリケーション機能のWebビュー内で開くことができるようにして、MAFアプリケーションをCSRF攻撃から保護します。リストに含まれないURIは、自動的にデバイスのブラウザ内、つまりモバイル・アプリケーションのサンドボックス外で開かれます。
インジェクション攻撃に加えて、モバイル・アプリケーションはクロスサイト・リクエスト・フォージェリ(CSRF)に対して脆弱であり、この攻撃では、悪意のあるページが、ユーザーIDを格納するWebブラウザにキャッシュされたCookieを使用して、ユーザーに代わってターゲット・アプリケーションで意図しないアクションを実行します。ホワイトリストとアプリケーション・サンドボックスを組み合せることで、CSRFの問題に対応します。
ネイティブ・コンテナにアクセスするアプリケーション機能(特に、リモートURLコンテンツのあるアプリケーション機能)を無効にすることも検討してください。MAFアプリケーション内の選択したアプリケーション機能がネイティブ・コンテナにアクセスできないようにすることもできます。たとえば、MAFアプリケーションには、信頼していないWebアプリケーションからリモート・コンテンツを参照するアプリケーション機能が含まれます(リモートURLコンテンツ・アプリケーション機能)。このシナリオでは、次の例に示すように、この特定のアプリケーション機能がネイティブ・コンテナにアクセスできないようにします。
<adfmf:featureReference refId="remoteAppfeature1" id="fr1" allowNativeAccess="false"/>
allowNativeAccessプロパティのデフォルト値はtrueです。
MAFアプリケーションでは、リモート・サーバーを介してユーザー・インタフェースが配信されるアプリケーションで、XSSおよびCSRF攻撃が発生する場合があります。リモートURLからコンテンツを取得するようにモバイル・アプリケーションを構成するときは、MAFで提供されている概要エディタを使用して、コンテンツを配信するURLのホワイトリストを作成できます。ホワイトリスト内のURLはMAF Webビューで開かれ、指定したデバイス機能およびサービスにアクセスできます。第21.1.1項「ホワイトリストを使用したリモート・アプリケーションによるデバイス・サービスへのアクセスの有効化」に示すように、ワイルドカードを使用してホワイトリストされたURIを構成できます。
|
注意: 意図しないURIがデバイス機能にアクセスするのを防止するには、特定のターゲット・ドメインに対してのみホワイトリストを定義します。ホワイトリスト内のドメインを定義するときは、ワイルドカードを慎重に使用してください。広範囲のURIを指定できるワイルドカードベースのホワイトリスト構成の定義は避けてください(たとえば、<adfmf:domain>*.*</adfmf:domain>などの構成は避けてください)。また、ドメイン名にワイルドカード・アスタリスク(*)を含めることはできますが、これらを末尾に指定することは表示できません(例: <adfmf:domain>example.*</adfmf:domain>)。 |
ホワイトリストに含めたURIは、ユーザーのデバイスに格納されたデータの他、カメラやアドレス帳などの様々なデバイス機能にアクセスできます。第10.2項「MAFアプリケーションでのコア・プラグインの有効化」に示すようなアクセスは、デフォルトでは付与されていませんが、MAFアプリケーションを構成して、ホワイトリストに含まれるURIがアクセスできるデバイスの機能を次のいずれかに制限できます。
オープン・ネットワーク・ソケット(ユーザー認証の構成時に許可する必要がある)
GPSおよびネットワークベースの位置情報サービス
連絡先
電子メール
SMS
電話
プッシュ通知
ローカルに格納されたファイル
|
ヒント: ホワイトリスト構成に加えて、updateSecurityConfigWithURLParametersメソッド(ログイン構成の変更を検出してから、再認証によって変更を確認するようにユーザーに求める)を使用して、XSSによって挿入された偽のログイン・ページなどのセキュリティ・リスクから、プログラムによりユーザーを保護することができます(第30.5.7項「実行時の名前付き接続の接続属性の更新方法」を参照)。さらに、MAFはユーザーが保護されたアプリケーション機能を開くたびに、ユーザーに通知します。デフォルト・アプリケーションにセキュリティが適用されないと、認証が遅延する可能性があります。詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。 |
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が適切にエンコードされていることを確認する必要があります。詳細は、第13.3.18項「Verbatimコンポーネントの使用方法」および第13.3.19項「出力HTMLコンポーネントの使用方法」を参照してください。また、第29.8項「信頼できない入力に対するセキュリティ決定」も参照してください。
iOSプラットフォームとAndroidプラットフォームの両方において、アプリケーション(Skypeなど)は必ずしも外部からの許可をリクエストするとは限らないため、攻撃者にエントリ・ポイントを提供して、悪意のあるアプリケーションがセキュリティを回避してしまう可能性があります。その結果、アプリケーションはクライアント側のインジェクションおよびデータ漏えいに対して脆弱になります。必ず追加の認可を求めるプロンプトを表示するか、あるいは追加の認可が可能でない場合は、保護を必要とするアプリケーションを起動するための追加のステップを提供してください。
アプリケーションが信頼できないサードパーティ・アプリケーションから受信する(またはこれらのアプリケーションに送信する)すべてのデータが、入力検証の対象となっていることを確認する必要があります。アプリケーションに対するクライアント側のXML入力を、エンコードおよび検証する必要があります。MAF AMXコンポーネントではユーザー入力を検証できますが、データはサーバー上で検証する必要があり、サーバーはクライアントから受信するデータを信頼しないようにする必要があります。つまり、サーバーとクライアントの間で送受信されるXML、JSONおよびJavaScriptが適切にエンコードされていることを確認する役割は、サーバーが担います。
別のアプリケーションからMAFアプリケーションを起動するURLスキームを構成するときは、URLを介して送信されるパラメータを検証して、悪意のあるデータまたはURIがMAFアプリケーションに渡される可能性がないことを確認する必要があります。詳細は、第21.4項「MAFアプリケーションでのカスタムURLスキームの使用」を参照してください。また、第29.1項「脆弱なサーバー側コントロール」も参照してください。
JSON解析について
可能な場合は、MAFのJSONエンコーディングAPIを使用します。カスタムJSON構成を必要とするシナリオでは、ユーザー入力データを使用してJSONを構成するときには注意が必要です。JSONデータの処理の詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。
モバイル・アプリケーションのユーザビリティ要件では、多くの場合、長期にわたって継続するセッションが求められます。モバイル・アプリケーションは、セッション管理にCookie、SSOサービスおよびOAUTHトークンを使用します。Oracle Access Management Mobile and Social (OAMMS)では、OAuthトークンがサポートされています。
|
注意: OAuthアクセス・トークンは、リモートで取り消すことができます。 |
適切なセッション処理を有効にするには:
ログイン・サーバー接続のセッション・タイムアウトを、サーバー側のセッション・タイムアウトよりも小さい値に構成します。
デバイスIDは期限切れになることがないため、セッション・トークンとして使用しないでください。アプリケーションでは、ユーザーが再認証を行う必要が生じても、トークンを期限切れにする必要があります。
サーバーでのトークン生成時に、適切なベスト・プラクティス(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projectの「OWASP Top Ten Project」を参照)に従っていることを確認してください。
容易に予測できるか、または適切に生成されていないセッション・トークンを使用しないでください。セッション・トークンは予測不能で、エントロピが高い必要があります。
Oracle Identity Management (IDM)スタックでは、モバイル・アプリケーションで使用するための標準ベースのトークン(OAuthアクセス・トークン、JWTトークンなど)がサポートされています。MAFでは、Oracle IDM OAuthサーバーに対して即時利用可能なサポートが提供されており、MAFアプリケーションでこのような標準ベースの認証メカニズムを使用することをお薦めします。
第30.5.3項「基本認証の構成方法」で説明されているように、ユーザーがログイン・サーバーに対して認証を行う必要があるアプリケーションの構成には、セッションの持続時間およびアイドル・タイムアウトを設定するオプションが含まれます。デフォルトでは、アプリケーション機能セッションの持続時間は8時間です。アプリケーション機能がアイドル状態にあるデフォルト時間は、5分間です。MAFでは、いずれかの構成期間が過ぎるとユーザー資格証明が期限切れになり、ユーザーに再認証を求めるプロンプトが表示されます。
攻撃者はリバース・エンジニアリングを使用して、APIキー、パスワード、機密ビジネス・ロジックなどの機密データを検出できます。この情報を保護するには:
APIキーおよび機密ビジネス・ロジックをサーバー上に格納します。
パスワードをアプリケーション・バイナリに格納しないでください。
パスワードをハードコード化しないでください。かわりに、第29.2項「デバイスでの安全でないデータ格納」で説明されているGeneratedPasswordユーティリティを使用します。
ログ・ファイルをモニターできるので、アプリケーションが機密情報をログ・ファイルに書き込まないことを確認します。第29.4項「サイドチャネルによるデータ漏えい」も参照してください。
情報がファイル・システム上に格納される(つまり、モバイル・アプリケーションの外部に格納される)ことに注意してください。機密データを暗号化されたデータベースまたはファイル・システム、あるいはネイティブ・キー・チェーンに格納します。リスク1:「デバイスでの安全でないデータ格納」も参照してください。
