ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発
2.0.1
E57592-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/)から入手できる『ファイル・システム・プログラミング・ガイド』の「ファイル・システムの基礎」の項も参照してください。

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

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

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

モバイル・アプリケーションは、プロバイダ・ネットワークを介してデータにアクセスするときにSSL/TLSを使用し、WiFiを使用する場合はこれらのどちらのプロトコルも使用しないことがあります。プロバイダ・ネットワークはハッキングされる可能性があるため、安全であることを想定しないようにしてください。したがって、アプリケーションが機密データをトランスポートするときはSSLを強制し、すべての証明書が有効で公的機関によって署名されていることを確認する必要があります。

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

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

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

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

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

20.5 不十分な認可および認証

不十分な認証メカニズムとクライアント側アクセス制御は両方とも、セキュリティを脅かします。

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

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

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

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

20.6 不適切な暗号化

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

  1. アプリケーションで間違った実装を使用しているか、または既知のアルゴリズムを不正に使用している。

  2. 暗号が容易に解読されるために、データが安全でない。

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

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

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

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

モバイル・アプリケーションは様々なソースからコンテンツおよびデータを取り出すため、ユーザー・セッションを乗っ取るクロスサイト・スクリプティング(XSS)インジェクションに対して脆弱である可能性があります。MAFは主にエンコーディングによってXSSを防止しますが、追加の安全策としてホワイトリストを使用します。

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

インジェクション攻撃に加えて、モバイル・アプリケーションはクロスサイト・リクエスト・フォージェリ(CSRF)に対して脆弱であり、この攻撃では、悪意のあるページが、ユーザーIDを格納するWebブラウザにキャッシュされた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.1項「デバイス機能へのアクセスの有効化方法」に示すようなアクセスは、デフォルトでは付与されていませんが、MAFアプリケーションを構成して、ホワイトリストに含まれるURIがアクセスできるデバイスの機能を次のいずれかに制限できます。

  • オープン・ネットワーク・ソケット(ユーザー認証の構成時に許可する必要がある)

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

  • 連絡先

  • 電子メール

  • SMS

  • 電話

  • プッシュ通知

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


ヒント:

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


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

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が適切にエンコードされていることを確認する必要があります。詳細は、第6.3.18項「Verbatimコンポーネントの使用方法」および第6.3.19項「出力HTMLコンポーネントの使用方法」を参照してください。また、第20.8項「信頼できない入力に対するセキュリティ決定」も参照してください。

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

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

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

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

  • アプリケーション開発者は、アプリケーションによって処理されるXMLおよびHTMLコンテンツをエンコードし、検証することが想定されています。

20.8 信頼できない入力に対するセキュリティ決定

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

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

別のアプリケーションからMAFアプリケーションを起動するURLスキームを構成するときは、URLを介して送信されるパラメータを検証して、悪意のあるデータまたはURIがMAFアプリケーションに渡される可能性がないことを確認する必要があります。詳細は、第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項「基本認証の構成方法」で説明されているように、ユーザーがログイン・サーバーに対して認証を行う必要があるアプリケーションの構成には、セッションの持続時間およびアイドル・タイムアウトを設定するオプションが含まれます。デフォルトでは、アプリケーション機能セッションの持続時間は8時間です。アプリケーション機能がアイドル状態にあるデフォルト時間は、5分間です。MAFでは、いずれかの構成期間が過ぎるとユーザー資格証明が期限切れになり、ユーザーに再認証を求めるプロンプトが表示されます。

20.10 バイナリ保護の欠如による機密情報の漏えい

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