JSSECセキュアコーディングガイドが改訂されました その2

前回（JSSECセキュアコーディングガイドが改訂されました その1）に引き続き、本改訂版で訂正・追加された内容についてご説明したいと思います。「exported設定とintent-filter設定の組み合わせ」は前回ご説明したので、今回はNetwork Security Configuration以降の内容についてをご説明します。
なお、JSSECセキュアコーディングガイド^*1 は、こちらより無料で閲覧・ダウンロードすることができます。

本改訂版における訂正記事は以下のとおりです(本改訂版 P16、17より一部抜粋)。

訂正記事である5.4.3.7について

本改訂版から「Network Security Configuration」に関する記述が追記されました。詳細については、本改訂版もしくはDevelopersサイトの「Network Security Configuration」に関する項目^*2 をご覧ください。

Network Security Configurationとは

Android 7.0(API Level 24)から導入された、アプリケーションのコードを変更することなく、ネットワークセキュリティ設定をアプリケーションごとにカスタマイズできる機能です。これらの設定は、特定のドメインに対して、また特定のアプリケーションに対して構成することができます。
主な機能は以下の4つです。

• Custom trust anchors
  セキュアな接続にどの認証局(CA)を信頼するかをカスタマイズ
• Debug-only overrides
  インストールベースに追加されるリスクなく、セキュアな接続を安全にデバック
• Cleartext traffic opt-out
  平文通信の意図しない使用からアプリケーションを保護
• Certificate pinning
  セキュアな接続を特定の証明書に制限

それぞれについて簡単に紹介します。

Custom trust anchors

デフォルトでは、アプリケーションにおけるすべてのセキュアな接続（TLS、STARTTLSなど）は、システムにプレインストールされているCAを信頼します。しかし、何かしらの理由により、プラットフォームのデフォルト設定ではなく、カスタマイズした一連のCAを信頼したいときに、domain-config（ドメイン単位のカスタマイズ）、base-config（domain-configに含まれていない全ての通信のカスタマイズ）を使用して、独自の接続をカスタマイズすることが可能です。

Debug-only overrides

HTTPSで接続するアプリケーションをデバッグする場合、本番サーバのSSL証明書がインストールされていないローカルの開発サーバへの接続が必要となる場合がありますが、本機能を用いることでアプリケーションのコードを変更することなくこの接続をサポートすることが可能となりました。debug-overridesを用いて、android:debuggableが「true」の場合にのみ信頼されるデバッグ限定のCAを指定することで、この接続をサポート可能です。

GooglePlayなどのアプリケーションストアでは、debuggableフラグが付いたアプリケーションをアップロードすることはできないため、通常の条件付コードよりも安全性が高くなります。

Cleartext traffic opt-out

アプリケーションでセキュアな接続のみを使用したい場合、その接続に対してHTTPを使用するようなクリアテキストで行う接続を除外することが可能です。これにより、バックエンドサーバなどの外部リソースが提供するURLの変更による偶発的な問題（センシティブな情報をHTTPで送ってしまうような問題）を防ぐことが可能となります。

本改訂版のP390に以下のような記載があります。

<domain-config>タグにcleartextTrafficPermitted="false"を属性値として設定することにより、特定ドメインとのHTTP通信が抑制され、HTTPS通信を用いることが強制される。同様の属性値を<base-config>タグに設定すると、全てのドメインに対するHTTP通信が抑制される。ただし、この設定はWebViewには適用されないことに注意する必要がある。

上記文面の通り、本機能はWebViewには適応されません。なお、WebView以外においても、すべてのクリアテキストで行われる接続を除外できるというわけではありません。
理由としては、DevelopersサイトのisCleartextTrafficPermittedの説明^*3 に以下の文面があるためです。

This flag is honored on a best effort basis because it's impossible to prevent all cleartext traffic from Android applications given the level of access provided to them. For example, there's no expectation that the Socket API will honor this flag because it cannot determine whether its traffic is in cleartext. However, most network traffic from applications is handled by higher-level network stacks/components which can honor this aspect of the policy.
NOTE: WebView does not honor this flag.

本文面はAPI Level 23のisCleartextTrafficPermittedに関する記述のため、API Level 24のisCleartextTrafficPermittedでは仕様が異なっている可能性がありますが、本文面からわかるとおり、完全ではなくベストエフォートで対応されます。また、本改訂版にも記載されていますが、WebViewは本フラグを受け付けないため、WebViewにおけるクリアテキストを用いた接続は除外することはできないのでご注意ください。なお、API Level 24のisCleartextTrafficPermittedに関しても、API Level 23のisCleartextTrafficPermittedを参照と記載されているため、同じ仕様であると思われます（確信できませんが...）。

Certificate pinning

通常、アプリケーションはシステムにプレインストールされている全てのCAを信頼します。そのため、万が一プレインストールされているCAが偽証明書を発行した場合、アプリケーションはman-in-the-middle attack（中間者攻撃）を受けてしまう危険性があります。実際に、CAが偽証明書や不正ドメインへの証明書を発行していたというニュースがあります。

中国の認証局が不正な証明書、主要ブラウザが無効化を通告 - ITmedia エンタープライズ
Certificate authorities issue SSL certificates to fraudsters | Netcraft

信頼するCAを制限する、もしくは証明書ピンニングを行うことで受け入れる証明書を制限し、本問題に対応することが可能です。
証明書ピンニング（Certificate pinning）という単語が出てきましたが、簡単に説明すると、接続先サーバの証明書のコピーをアプリケーション内に保存しておき、SSLハンドシェイクの際、実際の接続先サーバから送られてきたサーバ証明書の公開鍵が、アプリケーション内に保存されている証明書の公開鍵に一致するかを検証する仕組みのことです。

訂正記事である4.2.2.6、4.2.3.4について

以下の文面が追記されました（本改訂版 P118、123より）。

なお、Sticky Broadcastの使用はAndroid 5.0(API Level 21)において非推奨となっている。

Sticky Broadcastについて簡単にご説明します。本来、Intentオブジェクトの情報は一定期間しか保持されません。しかし、このSticky Broadcastを利用することで、端末が再起動するかremoveStickyBroadcast()メソッドが呼ばれるまで保持されます。Sticky Broadcastは、暗黙的インテントによる使用が前提とされているため、Sticky Broadcastで送信された情報は不特定多数のアプリケーションで取得することができます。つまり、Sticky Broadcastにセンシティブな情報を含めてはいけません（情報が他アプリに漏えいする可能性があるため）。

訂正記事である4.5.2.1、4.6.3.2について

以下の文面が追記されました（本改訂版 P256より）。また、P222においてもP256を参照する旨が追記されています。

MODE＿WORLD_READABLEおよびMODE_WORLD_WRITEABLEはAPI Level 17以降ではdeprecatedとなっており、API Level 24以降ではセキュリティ例外が発生するため使用できなくなっている。

MODE＿WORLD_READABLE、MODE_WORLD_WRITEABLEについて簡単にご説明します。2つとも、アプリケーションディレクトリ配下のサブディレクトリを取得・作成するためのメソッドの一つであるgetDir()^*4 におけるアクセス権設定の一部でした。現在は本改訂版で記載されている通り、使用できません。代わりに、ContentProvider、BroadcastReceiver、Serviceなどの機能を使用する必要があります。なお、MODE＿WORLD_READABLEは、他のすべてのアプリケーションに対して作成したファイルへの読み取り権限を与え、MODE＿WORLD_READABLEは、他のすべてのアプリケーションに対して作成したファイルへの書き込み権限を与える設定です。

訂正記事である4.6.3.5について

本改訂版から「Scoped Directory Access」に関する記述が追記されました。詳細については、本改訂版もしくはDevelopersサイトの「Scoped Directory Access」に関する項目^*5 をご覧ください。

Scoped Directory Accessとは

Android 7.0(API Level 24)から導入された、外部ストレージ（SDカードなど）の特定ディレクトリに対し、パーミッションを取得することなくアクセスできる機能です。今までは、外部ストレージにアクセスするためにREAD_EXTERNAL_STORAGEやWRITE_EXTERNAL_STORAGEのパーミッションを取得しなければなりませんでした。しかし、これらのパーミッションを取得すると、外部ストレージ上のすべてのディレクトリにアクセスできるようになり、アプリケーションが不要な場所にもアクセスできてしまう問題があります。
この問題を解決するために、Scoped Directory Accessでは、StorageVolume.createAccessIntent()メソッドを呼び出し、作成されたインテントを利用して外部ストレージにアクセスします。このStorageVolume.createAccessIntent()メソッドの引数にアクセスしたいディレクトリを指定することで、そのディレクトリにアクセスする際に画面上にアクセス許可を求めるダイアログが表示され、ユーザからの許可が得られた場合のみ、指定されたディレクトリへのアクセスが可能となります。

なお、指定可能なディレクトリは以下の通りです（本改訂版P258、259より）。

以上、前回（その1）に引き続き本改訂版で訂正・追加された内容について書かせていただきました。Androidアプリケーションを開発されている方で、JSSECセキュアコーディングガイドをご覧になったことがない方は一度ご覧になってみては如何でしょうか。また、JSSECセキュアコーディングガイドをご覧になったことがある方は本改訂版で訂正された記事をご覧いただくことをお勧めいたします。

• *1 『Androidアプリのセキュア設計・セキュアコーディングガイド』【2017年2月1日版】を公開しました。｜ JSSEC
• *2 Network Security Configuration | Android Developers
• *3 NetworkSecurityPolicy | Android Developers
• *4 Context | Android Developers
• *5 Using Scoped Directory Access | Android Developers

「JSSECセキュアコーディングガイドが改訂されました その1」へ