Oracle® Fusion Middleware Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発 2.0 E56274-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データベースの一般的な情報は、第10章「ローカル・データベースの使用方法」を参照してください。GeneratedPassword
、encryptDatabase
(およびこれに対応するdecryptDatabase
)の詳細は、Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスおよび第10.2.7項「データベースを暗号化および復号化する方法」を参照してください。サンプル・アプリケーションについては、PublicSamples.zip
のStockTrackerサンプルを参照してください(付録F「サンプルのモバイル・アプリケーション・フレームワーク・アプリケーション」を参照)。
注意:
|
adfmfJavaUtilties
クラスのgetDirectoryPathRoot
メソッドを使用すると、プログラムによってiOSとAndroidの両方のプラットフォーム上のローカル・ファイル・システムにファイルを格納できます。このメソッドを使用すると、デバイスにアプリケーション・データを格納するためにアグノスティック・アクセスが提供されます。このメソッドでは、次のオプションを使用できます。
一時ディレクトリ
アプリケーション・ディレクトリ
キャッシュ・ディレクトリ
ダウンロード・ディレクトリ
ヒント: ユーザーがデスクトップ・コンピュータにデバイスを同期する場合、デバイスのアプリケーション・ディレクトリに格納されているデータはデスクトップ・システムに転送され、ここで公開される可能性があります。一時ディレクトリにデータを格納します。iOSでは、iTunesを使用してデバイスが同期される場合、一時ディレクトリに格納されているデータはデスクトップと同期されません。 |
セキュリティを必要とするファイルの場合は、Java暗号化API (javax.crypto
)を使用して、ファイルを暗号化および復号化できます。javax.crypto
パッケージの詳細は、Java Platform, Standard Edition 1.4 APIを参照してください。詳細は、Oracle Fusion Middleware 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ツールを使用して表示できます。第20.4項「サイドチャネルによるデータの漏洩」も参照してください。
モバイル・アプリケーションは、プロバイダ・ネットワークを介してデータにアクセスする場合はSSL/TLSを使用できますが、WiFiを使用する場合はこれらのプロトコルのどちらも使用できません。プロバイダ・ネットワークはハッキングされる可能性があるため、安全であるとはかぎりません。そのため、アプリケーションで機密データを転送する場合はSSLを適用し、証明書のすべてが正規のものであり、公的機関によって署名されていることを検証する必要があります。
モバイル・アプリケーションで使用されるすべてのエンドポイントをSSLにより保護する必要があるため、MAFではSSLをサポートするWebサービス・ポリシー・セットを提供します。SOAP Webサービスの場合、MAFアプリケーションでは次のポリシーを使用します。
oracle/http_basic_auth_over_ssl_client_policy
oracle/wss_username_token_over_ssl_client_policy
oracle/wss_http_token_over_ssl_client_policy
REST Webサービスの場合、MAFは多数のSSLベースのポリシーをサポートしています。詳細は、第8.5.2項「RESTベースのWebサービスへのアクセスを有効にする方法」および第21.4.12項「CookieをREST Webサービス・コールに追加することに関する必知事項」を参照してください。
MAFでは、既知の信頼できる認証局のエントリでシードされたcacerts
ファイルを提供します。アプリケーション開発者は、必要に応じて他の証明書をこのファイルに追加できます。詳細は、第21.8項「SSLのサポート」を参照してください。
意図しないデータ漏洩は次のようなことに起因する可能性があります。
スクリーン・ショットの無効化(バックグラウンドでの実行): iOSおよびAndroidは、アプリケーションの再アクティブ化のパフォーマンスを向上させるためにアプリケーションをバックグラウンドで実行する前に、アプリケーションのスクリーン・ショットを取得します。ただし、これらのスクリーン・ショットはカスタマ・データの漏洩の可能性があるため、セキュリティ上の問題の原因となります。
キー・ストローク・ロギング: iOSおよびAndroidでは、キーボードで入力された一部の情報が、先行入力機能で使用するアプリケーション・ディレクトリに自動的に記録されます。この機能により、カスタマ・データの漏洩が発生する可能性があります。
デバッグ・メッセージ: アプリケーションは機密データをデバッグ・ログに書き込むことができます。ロギング・レベルを「FINE」に設定すると、ユーザーのデバイスとサーバー間で送信されるすべてのデータに対してログ・メッセージが書き込まれるようになります。
アプリケーションの一部として表示される機密文書に対して、クリップボード・コピー機能および開く機能を無効化します。MAFには現在、コピー機能および開く機能を無効化する機能はなく、今後のリリース対象となっています。
一時ディレクトリ: 機密情報が含まれる可能性があります。
サードパーティ・ライブラリ: これらのライブラリ(adライブラリなど)により、ユーザー、デバイスまたはユーザーのロケーションなどのユーザー情報が漏洩される可能性があります。
データ漏洩を防ぐには:
資格証明、個人を特定できる情報(PII)または他の機密データをアプリケーション・ログに記録しないでください。すべての機密情報をネイティブKeychain、または暗号化されたデータベースやファイル・システムに格納します。
アプリケーションをデバッグする場合、作成されたすべてのファイルおよびそれらのファイルに書き込まれていたすべてのデータを確認します。
アプリケーションを公開する前にデバッグ・メッセージを削除します。
脆弱な認証メカニズムとクライアント側アクセス制御のいずれによってもセキュリティが損なわれます。
エンド・ユーザーが、ユーザー名とパスワードではなく、電話番号またはいずれかのタイプの識別子(IMEI、IMSIまたはUUID)を使用してデバイスを認証するのは簡単ですが、これらの識別子は総当たり攻撃によって簡単に検出されるため、単独のオーセンティケータとして使用しないでください。かわりに、モバイル・アプリケーションでは、機密データにアクセスする場合、強力な資格証明を使用する必要があります。認証には、デバイスではなく、ユーザーが反映される必要があります。また、コンテキスト識別子(ロケーションなど)、音声、指紋または行動情報を使用して認証を強化できます。
開発者は、MAFが提供するデフォルト・ログイン・ページまたは開発者が作成するカスタム・ログイン・ページを使用できます。詳細は、第21.5.2項「ログイン・ページの指定方法」を参照してください。
セキュア・アクセスを必要とする、MAFアプリケーションのすべての機能でセキュリティを有効にする必要があります(第21.5.1項「認証を要求するようにアプリケーション機能を設定する方法」を参照)。
また、アクセス制御はクライアントではなく、サーバーによって実行する必要があります。この機能をクライアント・モバイル・アプリケーションに配置すると、安全性が低くなります。アクセス制御サービス(ACS)によって、開発者はサーバーに定義されたユーザー・ロール/権限を使用して、モバイル・アプリケーションのアクセス制御を実行できるようになります。アクセス制御サービスはRESTfulサービスであり、アプリケーション開発者は、アプリケーションに有効なユーザー・ロール/権限をフィルタ処理するためにこれを実装できます。アプリケーションでは数千ものユーザー・ロールをサポートできますが、サーバーが返すのはモバイル・アプリケーションに指定するロールのみです。詳細は、第21.4.16項「アクセス制御の構成方法」を参照してください。
暗号化は、次のような理由から正確でなくなります。
アプリケーションで不適切な実装が使用されたり、既知のアルゴリズムが適切に使用されていません。
簡単に検出される暗号化のため、データはセキュアではありません。
また、Base64エンコーディング、不明瞭化およびシリアライズは暗号化ではありません(暗号化と取り違えないようにしてください)。
データを正常に暗号化するには:
キーと暗号化されたデータを一緒に格納しないでください。
プラットフォーム固有のファイル暗号化APIまたは別の信頼できるソースを使用します。独自の暗号化を作成しないでください。
また、暗号化メソッド(第20.2項「デバイス上のセキュアでないデータ格納」を参照)を使用する埋込みSQLiteデータベースの保護に加えて、SSLを適用し、セキュアなWebサービス・コールを作成します(第20.3項「トランスポート・レイヤーの不十分な保護」を参照)。MAFでは、資格証明のセキュアな処理にOracle Access Manager for Mobile and Social IDM SDKを使用します。
モバイル・アプリケーションは様々なソースからコンテンツやデータを取得するため、ユーザー・セッションを盗むクロスサイト・スクリプティング(XSS)インジェクションを受けやすくなります。MAFでは主にエンコーディングを介してXSSを阻止しますが、追加の安全策としてホワイトリストを使用します。
ホワイトリストにより、許可されたドメインのみをアプリケーション機能のWebビュー内で開くことができるようにして、CSRF攻撃からMAFアプリケーションを保護します。このリストに含まれないURIは、モバイル・アプリケーションのサンドボックスの外側であるデバイスのブラウザ内で自動的に開きます。
インジェクション攻撃に加えて、モバイル・アプリケーションはクロスサイト・リクエスト・フォージェリ(CSRF)を受けやすくなりますが、この攻撃は、悪質なページで、Webブラウザにキャッシュされた、ユーザーIDを格納するCookieを介してユーザーになりすまし、ターゲット元アプリケーションの意図しないアクションを実行します。ホワイトリストとアプリケーションのサンドボックス化の組合せにより、CSRFの問題に対処します。
MAFアプリケーションでは、ユーザー・インタフェースがリモート・サーバーを介して配信されるアプリケーションにおいて、XSS攻撃およびCSRF攻撃が発生する可能性があります。モバイル・アプリケーションを構成してリモートURLからそのコンテンツを抽出する場合、MAFによって提供される概要エディタを使用すると、コンテンツを配信するURLのホワイトリストを作成できます。ホワイトリストされたURLはMAF Webビューで開かれ、指定されたデバイス機能およびサービスにアクセスできます。第13.1.1項「ホワイトリストを使用したリモート・アプリケーションによるデバイス・サービスへのアクセスの有効化」に示すように、ワイルドカードを使用してホワイトリストされたURIを構成できます。
注意: 意図しないURIによるデバイス機能へのアクセスを阻止するには、特定のターゲット・ドメインに対してのみホワイトリストを定義します。ホワイトリストに含まれるドメインを定義する場合、ワイルドカードは注意して使用し、様々なURIで使用できるワイルドカード・ベースのホワイトリスト構成は定義しないでください( |
ホワイトリストに含めるURIは、ユーザーのデバイスに格納されているデータとその様々なデバイス機能(カメラ、アドレス帳など)にアクセスできます。第21.6項「デバイス機能へのアクセスの許可」に示すようなアクセスは、デフォルトでは付与されていませんが、MAFアプリケーションを構成して、ホワイトリストに含まれるURIがアクセスできるデバイスの機能を次のいずれかに制限できます。
ネットワーク・ソケットのオープン(ユーザー認証が構成されている場合は付与する必要があります)
GPSおよびネットワーク・ベースの位置情報サービス
連絡先
電子メール
SMS
電話
プッシュ通知
ローカルに格納されたファイル
ヒント: ホワイトリスト構成に加えて、 |
HTMLを使用してMAF AMXページにカスタマ・ユーザー・インタフェース・コンポーネントを作成すると、アプリケーションがインジェクション攻撃を受けやすくなります。MAFでは、MAF AMXページのHTMLコンテンツ用に2つのコンポーネントを提供します(<amx:verbatim>
コンポーネントおよび<amx:outputHTML>
コンポーネント)。<amx:verbatim>
コンポーネントでは動的HTMLを使用できないため、インジェクション攻撃を受けることはありません。ただし、<amx:outputHTML>
コンポーネント(ELバインディングを介して動的HTMLコンテンツを配信する)は、そのsecurity
属性をnone
に構成されている場合は攻撃を受けやすくなります。デフォルトではこの属性はhigh
に設定され、フレームワークが様々なHTMLタグをエスケープしてJavaScript (onClick
イベントなど)を削除できます。none
に設定すると、iFrameコンポーネントおよびJavaScript (AMXページ内のAJAXリクエストを許可する)を有効化できるため、HTMLおよびJavaScriptが適切にエンコードされていることを確認する必要があります。詳細は、第6.3.18項「Verbatimコンポーネントの使用方法」および第6.3.19項「出力HTMLコンポーネントの使用方法」を参照してください。また、第20.8項「信頼できない入力のセキュリティ判断」も参照してください。
iOSとAndroidの両方のプラットフォーム上のアプリケーション(Skypeなど)は、常に外部パーティに権限をリクエストするわけではないため、攻撃者にエントリ・ポイントを提供することになり、悪質なアプリケーションがセキュリティを迂回する可能性があります。その結果、アプリケーションはクライアント側インジェクションおよびデータ漏洩に対して脆弱になります。追加の認可が不可能な場合は、常に追加の認可を要求するか、追加の手順を指定して、保護を必要とするアプリケーションを起動します。
信頼できないサードパーティ・アプリケーションから受信(またはこのアプリケーションに送信)するすべてのデータが入力検証の対象となることに注意してください。アプリケーションへのクライアント側XML入力はエンコードおよび検証される必要があります。MAF AMXコンポーネントはユーザー入力を検証できますが、データは、クライアントから受信するデータを信用しないサーバー上で検証する必要があります。つまり、サーバーにより、サーバーとクライアント間で交換されるXML、JSONおよびJavaScriptが適切にエンコードされるようになります。
MAFアプリケーションを別のアプリケーションをから起動するURLスキームを構成する場合、悪質なデータまたはURIをMAFアプリケーションに渡すことができないようにするためにURLを介して送信されるパラメータを検証する必要があります。詳細は、第4.4項「カスタムURLスキームを使用したモバイル・アプリケーションの起動」を参照してください。また、第20.1項「脆弱なサーバー側コントロール」も参照してください。
JSON解析について
可能であれば、MAFのJSONエンコーディングAPIを使用します。カスタムJSON構成を必要とするシナリオでは、ユーザーが入力したデータでJSONを構成する際には注意が必要です。JSONデータの処理の詳細は、Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスを参照してください。
モバイル・アプリケーションのユーザビリティ要件では、多くの場合、セッションを長期間継続することが必要になります。モバイル・アプリケーションは、セッション管理にCookie、SSOサービスおよびOAUTHトークンを使用します。Oracle Access Management Mobile and Social (OAMMS)では、OAuthトークンをサポートしています。
注意: OAuthアクセス・トークンはリモートで取り消すことができます。 |
適切なセッション処理を可能にするには:
ログイン・サーバー接続のセッション・タイムアウトをサーバー側セッション・タイムアウトより小さい値に構成します。
セッション・トークンは失効しないため、デバイスIDをセッション・トークンとして使用しないでください。アプリケーションがトークンを終了することによってユーザーに強制的に再認証させる場合でも、アプリケーションはトークンを終了する必要があります。
サーバーでのトークン生成の適切なベスト・プラクティス(OWASP Top Ten Project: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
を参照)を確認してください。
簡単に推測できたり、適切に生成されていないセッション・トークンを使用しないでください。セッション・トークンは、予測不可能で、高エントロピである必要があります。
Oracle Identity Management (IDM)スタックでは、モバイル・アプリケーションで使用する標準ベースのトークン(OAuthアクセス・トークン、JWTトークンなど)をサポートしています。MAFはOracle IDM OAuthサーバーの即時利用可能なサポートを提供しており、オラクル社では、MAFアプリケーションとともに標準ベースの認証メカニズムなどを使用することをお薦めします。
第21.4.2項「Basic認証の構成方法」に示すように、ユーザーにログイン・サーバーに対する認証を要求するアプリケーションの構成には、セッション・タイムアウトおよびアイドル・タイムアウトの期間を設定するオプションが含まれます。デフォルトでは、アプリケーション機能セッションの期間は8時間継続します。アプリケーション機能をアイドル状態にしておくデフォルトの時間は5分です。構成した期間が過ぎたり、ユーザーに再認証を求める場合、MAFでのユーザー資格証明は失効します。
リバース・エンジニアリングを使用すると、攻撃者はAPIキーなどの機密データ、パスワードおよび機密性の高いビジネス・ロジックを検出できます。この情報を保護するには、次のことを行います。
APIキーおよび機密性の高いビジネス・ロジックをサーバーに格納します。
アプリケーション・バイナリにパスワードを格納しないでください。
パスワードをハードコード化しないでください。かわりに、GeneratedPassword
ユーティリティを使用します(第20.2項「デバイス上のセキュアでないデータ格納」を参照)。
ログ・ファイルはモニターできるため、アプリケーションによって機密情報がログ・ファイルに書き込まれていないことを確認してください。第20.4項「サイドチャネルによるデータの漏洩」も参照してください。
ファイル・システム(つまり、モバイル・アプリケーションの外部で格納されている)に格納されている情報に注意してください。暗号化されたデータベースまたはファイル・システム、またはネイティブKeychainに機密データを格納します。リスク1: デバイス上のセキュアでないデータ格納も参照してください。