LAC WATCH

セキュリティとITの最新情報

RSS

株式会社ラック

メールマガジン

サイバーセキュリティや
ラックに関する情報をお届けします。

ラックピープル | 

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

2月9日(木)に「Androidアプリのセキュア設計・セキュアコーディングガイド」(以下、JSSECセキュアコーディングガイド)の改訂版が公開されました*1 。JSSECセキュアコーディングガイドは、こちらより無料で閲覧・ダウンロードすることができます。

セキュアコーディングガイド

ちなみに皆さん、このJSSECセキュアコーディングガイドはご存知でしょうか。Androidアプリケーションの開発やテストなどを行っている方々はご存知の方が多いかと思いますが、JSSECセキュアコーディングガイドをご存じない方のために簡単に紹介した後、本改訂版で訂正・追加された内容についてご説明したいと思います。詳細については本改訂版をご覧ください。

JSSECセキュアコーディングガイドは、一般社団法人日本スマートフォンセキュリティ協会(JSSEC)*2 の技術部会セキュアコーディンWGが公開している「Androidアプリケーション開発者向けのセキュア設計、セキュアコーディングのノウハウをまとめたTips集」です(JSSECセキュアコーディングガイド 2017年2月1日版(以下、本改訂版)P13より)。
2012年6月1日に初めて公開され、本改訂版を含めて7回更新されています。ラックもJSSECの会員企業で、私自身も本改訂版のレビューをさせていただきました。

このJSSECセキュアコーディングガイドには、以下のような情報が含まれています。

  • セキュア設計・セキュアコーディングの基礎知識
    Androidスマートフォン/タブレットにおける情報資産と機能資産、脅威(情報資産や機能資産を脅かす攻撃)および脅威から情報資産や機能資産を保護する方法について
  • 技術の活用方法
    Androidには、Activity、SQLite、intent、WebViewなどの様々なテクノロジーが存在するが、脆弱性を作り込むことなくそれらを活用するための方法について
  • セキュリティ機能の使用方法
    Androidに用意されている、暗号、電子署名、Permission、指紋認証機能などの様々なセキュリティ機能の使用方法について

また、JSSECセキュアコーディングガイドにはサンプルコードが記載されていますが、記載されなかったものも含めて、全てのサンプルコードをまとめたファイルもこちらで公開されています。

JSSECセキュアコーディングガイドの紹介はこれくらいにして、本改訂版で訂正・追加された内容についてご説明したいと思います。今回は、「exported設定とintent-filter設定の組み合わせ」の記事についてご説明します。(「Network Security Configuration」以降の内容については、JSSECセキュアコーディングガイドが改訂されました その2でご説明)

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

本改訂版の訂正記事 訂正の要旨
4.1.3.1 exported設定とintent-filter設定の組み合わせ(Activityの場合) intent-filter定義の有無に関わりなくActivityのexported属性を指定すべきである旨を追記しました。
4.2.3.1 使用してよいexported設定とintent-filter設定の組み合わせ(Receiverの場合) intent-filter定義の有無に関わりなくReceiverのexported属性を指定すべきである旨を追記しました。
4.4.3.1 exported設定とintent-filter設定の組み合わせ(Serviceの場合) intent-filter定義の有無にかかわりなくServiceのexported属性を指定すべきである旨を追記しました
(全般) Android 4.0.3(API Level 15)未満に関する記述を削除もしくは脚注に移動しました。
5.4.3.7 Network Security Configuration Network Security Configurationについての解説を記載しました。
(該当なし) ADTに関する記述を削除しました。
4.2.2.6 Sticky Broadcastにはセンシティブな情報は含めない
4.2.3.4 Broadcastの種類とその特徴
Sticky Broadcastの使用がAPI Level 21以降非推奨となった旨を追記しました。
4.5.2.1 DBファイルの配置場所、アクセス権を正しく設定する
4.6.3.2 ディレクトリのアクセス権設定
MODE_WORLD_READABLEおよびMODE_WORLD_WRITEABLEの使用がAPI Level 17以降非推奨となった旨を追記しました。
4.6.3.5 Android 7.0(API Level 24)における外部ストレージの特定ディレクトリへのアクセスに関する仕様変更について 外部ストレージへのアクセスに関する仕様がAPI Level 19において変更されたことについての解説を記載しました。

訂正記事である4.1.3.1、4.2.3.1、4.4.3.1について

3つともすべてexported設定とintent-filter設定の組み合わせに関する記事ですが、対象がActivity、Receiver、Serviceと異なっています。これらのActivity、Receiver、Serviceは、Androidに存在するコンポーネント(アプリケーションを構成する要素)です。
Androidのコンポーネントには、以下の4つが存在します。

  • Activity
    ユーザインタフェイス(UI)を提供するコンポーネントで、マニフェストファイル(AndroidManifest.xml)の<activity>要素で宣言します。
    Activityはユーザに対して画面を表示し、ユーザからのリクエストを受け取ります。Activity間の移動にはインテントを利用する必要があります。
  • BroadcastReceiver
    非同期通信を行うための仕組みで、マニフェストファイルの<receiver>要素で宣言します。また、ソースコード内に実装し、動的に利用することも可能です*3
    BroadcastReceiverは、アプリケーションとシステム間、アプリケーション間、アプリケーション内の通信に使用することができます。パーミッション設定には、送信側と受信側の2種類が存在します。
  • Service
    ユーザインタフェイスを持たないコンポーネントで、マニフェストファイルの<service>要素で宣言します。
    Serviceの実行中にアプリケーションが他のアクティビティへ移動したり、他のアプリケーションが起動したりした場合でも、バックグラウンドで処理を継続します。Serviceが提供する機能は、Serviceを実装しているアプリケーションのみではなく、他のアプリケーションからも使用することができます。
  • ContentProvider
    アプリケーション間でデータを共有するための仕組みで、マニフェストファイルの<provider>要素で宣言します。
    ContentProviderを用いることで、アプリケーションは、データの実体(ファイルなのか、データベースなのかなど)を意識することなくアクセスすることが可能になります。

また、インテント(intent) やintent-filterという単語も出てきましたが、それぞれ以下のようなものです。

  • intent
    アプリケーションがOSや他のアプリケーションと通信を行うための手段の一つです。インテントには、受け取り先を確定した上で通信を行う「明示的インテント」と、受け取り先を明示的には指定せずに、受け取り先を決定する条件のみ指定する「暗黙的インテント」が存在します。代表的な例としては、「明示的インテント」は同一アプリケーション内の画面遷移、「暗黙的インテント」は他のアプリケーションの呼び出しです。
  • intent-filter
    各コンポーネントが受け取るインテントを絞り込むための設定で、マニフェストファイルに記述します。

なぜ、コンポーネントが4つ存在するにもかかわらず、exported設定とintent-filter設定の組み合わせに関する記事がActivity、Receiver、Serviceの3つのみで、ContentProviderについて記載されていないかというと、ContentProviderはインテントを利用しないためです。

では、本改訂版で追記された文面について見ていきたいと思います。なお、追記された文面はActivity、Receiver、Serviceともに同様のため、Activityを例に説明します。

以下の文面が追記されました(本改訂版 P82より)。なお、Recieverの場合はP120に、Serviceの場合はP209に同様の文面が追記されています。

Activityのexported属性が無指定である場合にそのActivityが公開されるか非公開となるかは、intent-filterの定義の有無により決まるが、本ガイドではActivityのexported属性を「無指定」にすることを禁止している。前述のようなAPIのデフォルトの挙動に頼る実装をすることは避けるべきであり、exported属性のようなセキュリティ上重要な設定を明示的に有効化する手段があるのであればそれを利用すべきであると考えられるためである。

1文目の前半にあるとおり、DevelopersサイトのActivityの説明*4 には以下の記載があります。

If you do not have intent filters, the default value for this element is "false".

APIの仕組み上は、<activity>要素にintent-filterが定義されていなければ、exported属性は「false」となり、同じアプリケーションのコンポーネント、もしくはshareUserIdの指定によって同じIDを持っているアプリケーションだけしかActivityの起動が行えないようになります。しかし、本改訂版ではデフォルトの挙動に頼るのではなく、明示的に「android:exported="false"」と指定すべきであると記載されています。なお、Receiver*5 、Service*6 に関しても、それぞれのページに詳細が記載されています。

本改訂版には、デフォルトの挙動に頼る実装を避ける理由は明記されておりませんが、おそらく、デフォルトの挙動が変更される可能性があるためと考えられます。実際に、Android 4.2(API Level 17)以降の<provider>要素におけるexported属性のデフォルト値はtrueからfalseに変更されています。

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

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

この記事は役に立ちましたか?

はい いいえ