「ONETOPIヘッドライン」アプリの脆弱性を検査してみた：実録、Androidアプリの脆弱性を撲滅せよ！（前編）（2/2 ページ）

ONETOPIヘッドラインで見つかった脆弱性の傾向

　今回のONETOPIヘッドラインの検査結果をSDNAメンバーが確認した結果、大きく3種類の脆弱性があることが分かりました。

画面3　ONETOPI ヘッドラインアプリの脆弱性の傾向

　それぞれの脆弱性は以下のようなものです。

アクセス制御

　Androidアプリにおけるアクセス制御の脆弱性とは、ActivityやReceiverといったコンポーネントや、SharedPreference・DBといったファイルシステム上に配置されるファイルを、意図せず第三者からアクセス可能な状態にしてしまう問題です。コンポーネントのアクセス制御に不備がある場合、開発者が意図していないタイミング・用途で、他のアプリからコンポーネントが利用されてしまい、情報漏えいなどの問題が発生する危険性があります。

　IPAテクニカルウォッチ『Androidアプリの脆弱性』に関するレポートでも、Androidアプリの脆弱性の7割強が「アクセス制御の不備」に起因すると報告されているように、多くのAndroidアプリに見られる脆弱性です。

　Secure Coding Checkerでは、「Activityを作る」や「Broadcastを受信する」などで検出できます。

ログ出力

　Androidアプリにおけるログ出力の脆弱性とは、LogクラスのメソッドやSystem.out/errを使って、第三者に公開すべきではないセンシティブな情報をログ出力してしまう問題です。Android 4.0以前のバージョンの端末では、端末内の他アプリが出力されたログデータを読み出せてしまうため、情報漏えいの問題が発生する危険性があります。

　Secure Coding Checkerでは、「LogCatにログ出力する」で検出できます。

HTTPS通信

　AndroidアプリにおけるHTTPS通信の脆弱性とは、主にHTTPS通信におけるサーバ証明書の検証不備に起因する問題で、サーバ証明書検証に不備があると中間者攻撃（man-in-the-middle）と呼ばれる手法によって、暗号通信を第三者に盗聴されてしまう危険性があります。

　この脆弱性も多くのAndroidアプリに見られる脆弱性で、昨年10月にGoogle Playの人気無料アプリの8％に中間者攻撃の脆弱性があったとの研究結果が報告されています。

　Secure Coding Checkerでは、「HTTPSで通信する」や「WebViewを使う」で検出できます。

　それでは、ONETOPIヘッドラインで見つかった上記脆弱性について、検査結果を細かく確認し、安全なコードに修正していきたいと思います。

アクセス制御に関する脆弱性の修正

「アクセス制御に関する脆弱性」とは

　Androidアプリが持つコンポーネントのアクセス制御を正しく機能させる、つまり、他のアプリから意図せずアクセスされないようにするには、AndroidManifest.xmlでコンポーネントの公開設定を適切に設定し、他アプリからのアクセスを制限する必要があります。

　一例を挙げると、セキュアコーディングガイドでは、Activityのアクセス制御の設定に際して、Activityの用途を「公開」「非公開」「パートナー限定」「自社限定」に分類し、それぞれの用途に応じてexported属性とintent-filterの定義を表3の通りに組み合わせ使用するよう定めています。

　コンポーネントの公開設定を誤ると、そのコンポーネントが開発者の意図していない用途で他のアプリから利用されたり、致命的な情報漏えいにつながったりします。過去の例を見ると、JVN31860555として報告されている問題などが、アクセス制御の脆弱性が原因で発生した問題です。

Secure Coding Checkerの結果確認

　ONETOPI ヘッドラインの場合、Activity、Broadcast receiver、Content provider、Serviceのほぼすべてに共通して、他のアプリからの情報参照の可否を設定する「exported属性（値）が正しく設定されていない」と指摘されていました（画面4）。

画面4　Activityの検査結果画面（一部抜粋）

コードの修正方法

　アプリの仕様に関する質問に回答した結果、Activity、Broadcast receiver、Content provider、Serviceで検出された脆弱性は、コンポーネントの公開設定に関するもののみとなりました。

　高間さんはONETOPIヘッドラインで使用される全てのコンポーネントについて、公開設定を見直しました。コンポーネントの検出項目で表示されているセキュアコーディングガイドへリンクをクリックすると、ガイドの該当個所が表示されます。膨大なガイドの記述の中から、コンポーネントの公開設定に関連する内容を集中的に学び、コードを修正できるようになっています。

　高間さんは以下のように、他のアプリから利用されるコンポーネントにはexported = “true” を、利用されるべきでないコンポーネントにはexported = “false” を書き加えました。

    <activity 
        android:name=".CategoryActivity"
        android:label="@string/app_name"
        android:launchMode="singleTask"
        android:screenOrientation="portrait"
    > 
    <receiver
        android:name=".alarm.AlarmInitReceiver"
    >

    <activity 
        android:name=".CategoryActivity"
        android:label="@string/app_name"
        android:launchMode="singleTask"
        android:screenOrientation="portrait"
        android:exported="true"
    >
   <receiver
        android:name=".alarm.AlarmInitReceiver"
        android:exported="false"
    >

　コンポーネントの公開設定を修正すると、以下のように、「違反」と判定されていた項目はすべて「安全」となり、コンポーネントの脆弱性が解消されていることが確認できました（画面5）。

画面5 コード修正後のActivityの検査結果画面（一部抜粋）

　引き続き後編では、Log出力に関する脆弱性の修正手順などを紹介します。