ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発
2.0
E56274-01
  目次へ移動
目次

前
 
次
 

20 セキュリティに関するベスト・プラクティス

モバイル・アプリケーション・フレームワークでは、次の各項で説明する、Open Web Application Security Project (OWASP)によって示された一般的なセキュリティ・リスクに対する保護を提供します。

20.1 脆弱なサーバー側コントロール

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

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

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

20.2.1 SQLiteデータベースの暗号化

MAFの埋込みSQLiteデータベースは、ローカルに格納されているデータを保護します。MAFアプリケーションでは、SQLiteデータベースを共有せず、データベースを作成するアプリケーションのみがデータベースにアクセスできるアプリケーションとなります。さらに、正しいユーザー名とパスワードを持つユーザーのみが、このデータベースにアクセスできます。AdfmfJavaUtilitiesクラスを使用して、キーを作成し、このデータベースのパスワードを保護したり、このデータベース内に格納されているデータを暗号化することもできます。データベースへのセキュア・キーを提供するために、AdfmfJavaUtilitiesクラスには、強力なパスワードを生成して安全に格納するGeneratedPasswordユーティリティ・クラスが含まれます。また、AdfmfJavaUtilitiesクラスは、パスワードによりデータベースを暗号化するためのencryptDatabaseメソッドも提供します。SQLiteデータベースの一般的な情報は、第10章「ローカル・データベースの使用方法」を参照してください。GeneratedPasswordencryptDatabase (およびこれに対応するdecryptDatabase)の詳細は、Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスおよび第10.2.7項「データベースを暗号化および復号化する方法」を参照してください。サンプル・アプリケーションについては、PublicSamples.zipのStockTrackerサンプルを参照してください(付録F「サンプルのモバイル・アプリケーション・フレームワーク・アプリケーション」を参照)。


注意:

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


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

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」の項も参照してください。

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

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

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

モバイル・アプリケーションは、プロバイダ・ネットワークを介してデータにアクセスする場合はSSL/TLSを使用できますが、WiFiを使用する場合はこれらのプロトコルのどちらも使用できません。プロバイダ・ネットワークはハッキングされる可能性があるため、安全であるとはかぎりません。そのため、アプリケーションで機密データを転送する場合はSSLを適用し、証明書のすべてが正規のものであり、公的機関によって署名されていることを検証する必要があります。

モバイル・アプリケーションで使用されるすべてのエンドポイントをSSLにより保護する必要があるため、MAFではSSLをサポートするWebサービス・ポリシー・セットを提供します。SOAP Webサービスの場合、MAFアプリケーションでは次のポリシーを使用します。

REST Webサービスの場合、MAFは多数のSSLベースのポリシーをサポートしています。詳細は、第8.5.2項「RESTベースのWebサービスへのアクセスを有効にする方法」および第21.4.12項「CookieをREST Webサービス・コールに追加することに関する必知事項」を参照してください。

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

20.4 サイドチャネルによるデータの漏洩

意図しないデータ漏洩は次のようなことに起因する可能性があります。

データ漏洩を防ぐには:

20.5 脆弱な認可および認証

脆弱な認証メカニズムとクライアント側アクセス制御のいずれによってもセキュリティが損なわれます。

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

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

セキュア・アクセスを必要とする、MAFアプリケーションのすべての機能でセキュリティを有効にする必要があります(第21.5.1項「認証を要求するようにアプリケーション機能を設定する方法」を参照)。

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

20.6 不適切な暗号化

暗号化は、次のような理由から正確でなくなります。

  1. アプリケーションで不適切な実装が使用されたり、既知のアルゴリズムが適切に使用されていません。

  2. 簡単に検出される暗号化のため、データはセキュアではありません。

また、Base64エンコーディング、不明瞭化およびシリアライズは暗号化ではありません(暗号化と取り違えないようにしてください)。

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

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

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

モバイル・アプリケーションは様々なソースからコンテンツやデータを取得するため、ユーザー・セッションを盗むクロスサイト・スクリプティング(XSS)インジェクションを受けやすくなります。MAFでは主にエンコーディングを介してXSSを阻止しますが、追加の安全策としてホワイトリストを使用します。

ホワイトリストにより、許可されたドメインのみをアプリケーション機能のWebビュー内で開くことができるようにして、CSRF攻撃からMAFアプリケーションを保護します。このリストに含まれないURIは、モバイル・アプリケーションのサンドボックスの外側であるデバイスのブラウザ内で自動的に開きます。

インジェクション攻撃に加えて、モバイル・アプリケーションはクロスサイト・リクエスト・フォージェリ(CSRF)を受けやすくなりますが、この攻撃は、悪質なページで、Webブラウザにキャッシュされた、ユーザーIDを格納するCookieを介してユーザーになりすまし、ターゲット元アプリケーションの意図しないアクションを実行します。ホワイトリストとアプリケーションのサンドボックス化の組合せにより、CSRFの問題に対処します。

20.7.1 ホワイトリストによるXSSからのアプリケーションの保護

MAFアプリケーションでは、ユーザー・インタフェースがリモート・サーバーを介して配信されるアプリケーションにおいて、XSS攻撃およびCSRF攻撃が発生する可能性があります。モバイル・アプリケーションを構成してリモートURLからそのコンテンツを抽出する場合、MAFによって提供される概要エディタを使用すると、コンテンツを配信するURLのホワイトリストを作成できます。ホワイトリストされたURLはMAF Webビューで開かれ、指定されたデバイス機能およびサービスにアクセスできます。第13.1.1項「ホワイトリストを使用したリモート・アプリケーションによるデバイス・サービスへのアクセスの有効化」に示すように、ワイルドカードを使用してホワイトリストされたURIを構成できます。


注意:

意図しないURIによるデバイス機能へのアクセスを阻止するには、特定のターゲット・ドメインに対してのみホワイトリストを定義します。ホワイトリストに含まれるドメインを定義する場合、ワイルドカードは注意して使用し、様々なURIで使用できるワイルドカード・ベースのホワイトリスト構成は定義しないでください(<adfmf:domain>*.*</adfmf:domain>または<adfmf:domain>*.com</adfmf:domain>などの構成は避けます)。


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

ホワイトリストに含めるURIは、ユーザーのデバイスに格納されているデータとその様々なデバイス機能(カメラ、アドレス帳など)にアクセスできます。第21.6項「デバイス機能へのアクセスの許可」に示すようなアクセスは、デフォルトでは付与されていませんが、MAFアプリケーションを構成して、ホワイトリストに含まれるURIがアクセスできるデバイスの機能を次のいずれかに制限できます。

  • ネットワーク・ソケットのオープン(ユーザー認証が構成されている場合は付与する必要があります)

  • GPSおよびネットワーク・ベースの位置情報サービス

  • 連絡先

  • 電子メール

  • SMS

  • 電話

  • プッシュ通知

  • ローカルに格納されたファイル


ヒント:

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


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

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項「信頼できない入力のセキュリティ判断」も参照してください。

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

モバイル・アプリケーションは、攻撃者が埋込みSQLiteデータベースに格納されているデータを読み取ることができるようにするSQLインジェクションに対して脆弱です。

SQLインジェクションを防ぐには:

  • アプリケーション開発者は、ローカル・データベースに格納されているすべてのデータを検証し、エンコードする必要があります。

  • アプリケーション開発者は、アプリケーションによって処理されるXMLおよび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リファレンスを参照してください。

20.9 不適切なセッション処理

モバイル・アプリケーションのユーザビリティ要件では、多くの場合、セッションを長期間継続することが必要になります。モバイル・アプリケーションは、セッション管理にCookie、SSOサービスおよびOAUTHトークンを使用します。Oracle Access Management Mobile and Social (OAMMS)では、OAuthトークンをサポートしています。


注意:

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


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

第21.4.2項「Basic認証の構成方法」に示すように、ユーザーにログイン・サーバーに対する認証を要求するアプリケーションの構成には、セッション・タイムアウトおよびアイドル・タイムアウトの期間を設定するオプションが含まれます。デフォルトでは、アプリケーション機能セッションの期間は8時間継続します。アプリケーション機能をアイドル状態にしておくデフォルトの時間は5分です。構成した期間が過ぎたり、ユーザーに再認証を求める場合、MAFでのユーザー資格証明は失効します。

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

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