スマートフォン向けのアプリ開発環境は、AppleやGoogleといったプラットフォームのメーカーが提供するものに限らずさまざまなものが存在する。純粋な開発環境もあればSDK（ソフトウェア開発キット）のようにパッケージ化されたものなど、スタイルもさまざまだ。

2015年に取り沙汰されたのは、特にバックドアなどを勝手にアプリに仕込んでしまうような開発環境だった。Moplusも偽XCODEも中国発の話題であったが、日本で同じような問題は起こり得ないのだろうか。この件について、スマホアプリ開発におけるリスクエヴァンジェリストとして知られる谷口岳氏に話を伺ってみた。

「どの開発環境、SDKで開発したとしてもリスクは存在する」

これが谷口氏の見解である。氏によれば、リスクはまず、開発環境がオープンソースか否かで大きく分かれる。

オープンソースであれば、問題点を自ら修正することや、解決済みのものを早期に入手し対応することは可能である。だが、そうでない場合、問題修正したものが提供されない限りリスクは残り続けることになる。パッチなどでの対応が可能な場合もあるが、ライセンス違反になる可能性もあるため、根本的な解決は提供側に委ねられることになる。

しかし、オープンソースだからといって開発環境のリスクを全て事前チェックしたり、ビルドされた最終アプリのリスクを事細かにチェックしたりする開発者は決して多くはないだろう、と谷口氏は述べている。

「かなり高いレベルのプロフェッショナルが人力でリスクを深掘りしても、数日は掛かります。これにはハイレベルの技術者を担保することはもちろん、コストや労力が掛かるため、きちんとしたチェックを行っていないアプリが市場に出回っていることは否めません」

例えば、非常に多く報告されるものとして、サーバー証明書の検証不備が挙げられる。SSLで通信している際に、通信データの盗聴や、改ざん、不正サーバーへの接続などが発生するとSSL例外が発生し、アプリは異常を検知できるようになっているのである。

サーバー証明書の検証不備

ところが、発生したSSL例外を無視するように実装されたアプリや、不正サーバーへ接続しても例外を発生しないように実装されたアプリが多くある。

同氏によれば、チェックすべき項目は膨大にあり、最低でも下記の点に留意しなければならないという。

Activityの脆弱性

• Serviceの脆弱性
• ContentProviderの脆弱性
• BroadcastReceiverの脆弱性
• AndroidManifest.xmlの脆弱性
• 使用できないPermission
• 不要なPermission
• 外部記憶装置へのアクセス
• ファイルのアクセス制限不備
• Log出力メソッドの使用
• JavaScriptか使用可能なWebView
• JavaScriptを使用しているAsset内HTMLファイル
• SSL通信時の証明書検証不備
• アプリ内に含まれているURL
• 安全性の低い暗号化ロジック
• プログラム内に取り組まれているライブラリの問題

誤った証明書の使用

• AndroidManifest.xml内の不要な項目
• デバッグモードの設定
• OSバージョン固有の問題
• 廃止されたAPIの使用
• プライバシーに配慮が必要な処理
• Android推奨ルールからの逸脱
• 実行時エラーとなる可能性
• グレーゾーンアプリの疑いのあるPermissionの使用
• 危険なPermissonの使用
• 広告ライブラリの使用
• 危険なライブラリの使用
• グレーゾーンのライブラリ使用

こうしたチェック項目を全て挙げると、およそ500項目に上る。これらのチェック工数の予算を担保しなければ、これらのリスクは確認されることなく市場に出回ってしまう。そのため、発注者側がもし納品されるアプリのセキュリティリスクを最小限にしたいのであれば、まず、これらのリスクを確認する工数とコストを開発者側と綿密に打ち合わせる必要があるのである。

そして何よりも、安全なアプリケーションを提供するという姿勢を持つことが重要と言えるだろう。