mobile security

【アプリ開発】OWASP Mobile Top 10 2016|Android/iOSアプリをセキュアに開発するTipsまとめてみました。

投稿日: カテゴリー: セキュアコーディング
Pocket

今回は『OWASP Mobile Top 10 2016』に基づいてアプリをセキュアに開発するにはどんな点を確認し、対策を実装すれば良いかなるべく実践的なTipsをまとめてみました。

Android/iOSアプリのセキュアな実装と言うと、一般的にはAndroidであればJSSEC、『Androidアプリのセキュア設計・セキュアコーディングガイド』が有名ですし、iOSであれば

セキュアコーディングガイド – Apple Developer』が有名だと思います。

ただWebアプリケーションのセキュリティの統一的な観点としてOWASP Top 10が外せないようにOWASP Mobile Top 10 2016も外すことができません。ただ具体的にどの部分の実装について確認しどのように対策すればいいかのリファレンスがイマイチ世の中に存在しないと感じたため今回の記事にすることを考えました。

それではM1プラットフォーム機能の不適切な利用(Improper Platform Usage)からM10関係のない機能|Extraneous Functionalityまで各項目別に紹介していきたいと思います。

なお、owasp.org原文につきましてはhttps://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10より引用させて頂いております。

SmartPhoneSecurity
SmartPhoneSecurity

M1 プラットフォーム機能の不適切な利用|Improper Platform Usage

本カテゴリは、プラットフォーム機能の誤用や、プラットフォームセキュリティ制御の不使用を対象としています。

これには、Android のIntent、プラットフォームのアクセス許可、TouchID(指紋認証センサー)の誤用、キーチェーン(パスワード管理)、またはモバイルOSの一部であるその他のセキュリティ制御が含まれます。

owasp.org原文

This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk.

Android/iOSアプリ開発に関連ある技術

インテント・TouchID・Keychain(iOS)/Android KeyStore Provider(Android)・Hardware credential storage(Android)

Android/iOSアプリに関する脆弱性の確認方法と対策

Android KeyStore Provider(Android 6.0(4.3は限定的))

このAndroid Key Store Providerではこのアプリ以外で利用できない可能な鍵を生成・保持することができます。

生成は以下のような感じで書きます。

/*
 * Generate a new EC key pair entry in the Android Keystore by
 * using the KeyPairGenerator API. The private key can only be
 * used for signing or verification and only with SHA-256 or
 * SHA-512 as the message digest.
 */
KeyPairGenerator kpg = KeyPairGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
kpg.initialize(new KeyGenParameterSpec.Builder(
        alias,
        KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY)
        .setDigests(KeyProperties.DIGEST_SHA256,
            KeyProperties.DIGEST_SHA512)
        .build());

KeyPair kp = kpg.generateKeyPair();

取り出す時は以下のように書きます。

KeyStore ks = KeyStore.getInstance("AndroidKeyStore");
ks.load(null);
KeyStore.Entry entry = ks.getEntry(alias, null);
PrivateKey privateKey = ((KeyStore.PrivateKeyEntry) entry).getPrivateKey();

M2 安全でないデータ保存|Insecure Data Storage

本カテゴリは、OWASP Top10 Mobile Risks 2014のM2(Insecure Data Storage:安全でないデータ保存)とM4(Unintended Data Leakage:意図しないデータ漏えい)を組み合わせた新しいカテゴリです。

owasp.org原文

This new category is a combination of M2 + M4 from Mobile Top Ten 2014. This covers insecure data storage and unintended data leakage.

Android/iOSアプリ開発に関連ある技術

データベース(SQLite/realm/localstorage)・システムログ(Logcat/SYSLOG)・Plistファイル(主にiOS)・XML(主にAndroid Shared Prefence等)・バイナリデータストア(Cookiebinary)・Cookieストア

Android/iOSアプリに関する脆弱性の確認方法と対策

Shared Preferences(Android)

機微情報保存前にサーバ側で取得した鍵を用いて暗号化した後、鍵は削除し再アクセス時の認証を持って複合鍵を取得するように実装します。

明示的にMODE_PRIVATEを指定し、自身のアプリからしかアクセスできないようにします。

SharedPreferences preference = getSharedPreferences(cryptdata, MODE_PRIVATE);
確認のポイント

機微情報をファイルに保存する際は暗号化すること、そして鍵は端末内にハードコードや期限なく端末に保存せすに以下のような方法で管理しているかを確認します。

①外部サーバにて管理する

②端末内の暗号鍵を外部サーバを用いて短い間隔で鍵を更新する

③端末完結のアプリではKeychainなど安全なプラットフォーム機能を用いて鍵を管理する

SQLite(Android)

SQLiteOpenHelperを継承したサブクラスを作成すると格別何も指定しなくともプライベート権限のファイルを作成することができます。

public class SampleSQLiteOpenHelper extends SQLiteOpenHelper{
    public SampleSQLiteOpenHelper(Context context){
        super(context, DB_NAME, null, DB_VERSION);
    }

}

Context#openOrCreateDatabaseの使用する場合、明示的にMODE_PRIVATEを指定し、

自アプリからしかアクセスできないようにします。

db = Context.openOrCreateDatabase("important.db", MODE_PRIVATE, null);

M3 安全でない通信|Insecure Communication

本カテゴリは、脆弱なハンドシェイク、不適切なSSLバージョン、脆弱なネゴシエーション、機密情報を含む平文通信などを対象としています

owasp.org原文

This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc.

Android/iOSアプリ開発に関連ある技術

証明書検証・Certificate and Public Key Pinning・ATS(App Transport Security)

Android/iOSアプリに関する脆弱性の確認方法と対策

証明書検証の不備確認ポイント(Android)

① TrustManagerを変更しない、独自のTrustManagerを作らない

脆弱な例:下記コードでは証明書チェーンの検証をしない実装となっています。

KeyManager[] keyManagers = null;
TrustManager[] transManagers = { new X509TrustManager() {
public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {}
public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {}
public X509Certificate[] getAcceptedIssuers() {
                return new X509Certificate[0];
        }
} };

② HostnameVerifierを変更しない、独自のHostnameVerifierを作らない


脆弱な例:URLのホスト名とCommon Nameが一致していることの検証をしていない

connection.setHostnameVerifier(new HostnameVerifier() {
     public boolean verify(String hostname, SSLSession sslSession) {
           return true;
     }
});

③ SSLExceptionに対し(throwするだけでなく)適切な例外処理をする

証明書の例外(SSLHandshakeException)については「HTTPS および SSL によるセキュリティ」にあるように以下のいずれかの理由で発生します。

  1. サーバー証明書を発行した CA が不明である
  2. CA によってサーバー証明書が署名されていないが、自己署名されている
  3. サーバー設定に中間 CA がない

M4サーバ側アプリケーションの安全でない認証|Insecure Authentification

本カテゴリは、エンドユーザの認証やセッション管理の不備を対象としています。

・必要なときにユーザを特定できない

・必要なときにユーザの同一性を維持できない

・セッション管理の不備

owasp.org原文

This category captures notions of authenticating the end user or bad session management. This can include:

・Failing to identify the user at all when that should be required

・Failure to maintain the user’s identity when it is required

・Weaknesses in session management

Android/iOSアプリ開発に関連ある技術

 

Android/iOSアプリに関する脆弱性の確認方法と対策

(CWE-598)GETパラメータにセッションや認証情報など機微情報が指定されることによりブラウザの履歴やリファラーなどから、それらの情報が取得される可能性のある実装などもこのカテゴリに含まれます。

M5不十分な暗号化|Insufficient Cryptography

コードは機密情報に暗号を適用しますが、暗号手法によっては不十分なことがあります。M3(Insecure Communication:安全でない通信)には、TLSやSSLに関連するあらゆるものが含まれています。また、もし暗号化すべきときにアプリが暗号を使用しない場合はM2(Insecure Data Storage:安全でないデータ保存)に含まれます。

本カテゴリは、暗号化が試行されたにもかかわらず、正しく実行されなかった問題を対象としています。

owasp.org原文

The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all when it should, that probably belongs in M2. This category is for issues where cryptography was attempted, but it wasn’t done correctly.

Android/iOSアプリ開発に関連ある技術

 

Android/iOSアプリに関する脆弱性の確認方法と対策

 

M6クライアント側の安全でない認可制御|Insecure Authentification

本カテゴリは、クライアント側の認可決定や強制ブラウジングなどの認可制御の不備を対象としています。これは、デバイス登録やユーザ識別といった認証の問題とは異なるものです。

もし、必要な状況でアプリがユーザを全く認証していない場合、それは認証の不備(M4)であり、本カテゴリに含まれません (たとえば、認証されて許可されたアクセスが必要にもかかわらず、一部のリソースやサービスへの匿名アクセスが許可されているなど)。

owasp.org原文

This is a category to capture any failures in authorization (e.g., authorization decisions in the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrolment, user identification, etc.).

If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then that is an authentication failure not an authorization failure.

Android/iOSアプリ開発に関連ある技術

 

Android/iOSアプリに関する脆弱性の確認方法と対策

必要最低限な文字や文字種が十分でない脆弱なパスワードポリシーはここにがいとうします。以下2016年の最も『多い』パスワードランキングですが、自由に付けさせるとこんなにも脆弱なパスワードをつけてしまうのでパスワードポリシーの時点でしっかり食い止めましょう。

脆弱パスワード

出典:Keeper Security)

M7クライアント側アプリケーションのコード品質|Client Code Quality

本カテゴリは、OWASP Top10で今まであまり使用されていなかったカテゴリの1つである、「Security Decisions Via Untrusted Inputs:信頼できない入力によるセキュリティ決定」というものでした。

本カテゴリでは、モバイルクライアントにおけるコードレベルの実装におけるすべての問題を対象としています。これは、サーバサイドのコーディングミスとは異なるものです。

本カテゴリには、バッファオーバーフローやフォーマットストリングの脆弱性のような、モバイルデバイス上で実行されているいくつかのコードを書き換えることにより解決できる様々なコードレベルのミスが含まれています。

owasp.org原文

This was the “Security Decisions Via Untrusted Inputs”, one of our lesser-used categories. This would be the catch-all for code-level implementation problems in the mobile client. That’s distinct from server-side coding mistakes. This would capture things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that’s running on the mobile device.

Android/iOSアプリ開発に関連ある技術

API・ライブラリ

Android/iOSアプリに関する脆弱性の確認方法と対策

AndroidであればJSSEC、『Androidアプリのセキュア設計・セキュアコーディングガイド』が有名ですし、iOSであれば

セキュアコーディングガイド – Apple Developer』に書いてあるようなことがこの項目に該当します。

非常に幅広く該当するので上記2つのセキュアコーディングガイドについて記事にする際に詳細は解説します。

 

M8コードレベルの改竄|Code Tampering

本カテゴリは、バイナリパッチ、ローカルリソースの改ざん、静的メソッド改竄、動的メソッド改竄、動的メモリ改竄を対象としています。

アプリケーションがモバイルデバイスに配信されると、コードとデータのリソースが端末に常駐することになります。攻撃者は、このコードを直接改ざんしたり、メモリ内容を動的に改ざんしたり、アプリケーションが使用するシステムAPIを改ざんまたは置き換えたり、アプリケーションのデータとリソースを改ざんすることが可能です。

owasp.org原文

This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.

Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.

 

Android/iOSアプリ開発に関連ある技術

root化・Jailbreak・プロセス侵害検知

Android/iOSアプリに関する脆弱性の確認方法と対策

 

M9リバースエンジニアリング|Reverse Engineering

本カテゴリは、ソースコード、ライブラリ、アルゴリズム、その他の資産を決定するための最終的なコアバイナリの分析を対象としています。

IDA Pro、Hopper、otool、その他のバイナリ検査ツールのようなソフトウェアによって、攻撃者はアプリケーションの内部構造を把握することが可能です。これによって、バックエンドサーバ、暗号の定数と暗号、知的財産に関する情報が明らかにされるだけではなく、アプリケーションに存在する他の初期の脆弱性を悪用するために使用される恐れがあります。

owasp.org原文

This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application. This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back end servers, cryptographic constants and ciphers, and intellectual property.

Android/iOSアプリ開発に関連ある技術

難読化(Pro guard)

Android/iOSアプリに関する脆弱性の確認方法と対策

難読化(Pro guard)を行う。ただしソースを追う分にはIDEなどに入れれば関連付けをやってソーストレースにはそれほど差異が生まれません。

リバースエンジニアリングにより、ハードコードされた暗号鍵が見付かることもしばしばあります。

暗号鍵がソースコード内にハードコードされていることにより、同一アプリケーションを利用している全ユーザのデータ暗号化鍵を取得されてしまう状態となってしまいます。
これにより暗号化されているデータを容易に復号されてしまう為、共通の方法で第三者に重要データを閲覧されてしまう可能性があります。

また、復号用のプログラムもリバースエンジニアリングにより簡単に作れてしまう点も頭に入れておくべきです。

M10関係のない機能|Extraneous Functionality

本カテゴリは、バックドア機能やその他の内部開発セキュリティコントロールを対象としています。これらは、開発者が本番環境にリリースするつもりではないバックドアなどを含めてしまうことが原因です。

例えば、開発者が誤ってハイブリッドアプリのコメントにパスワードを含めたり、テスト中に無効化した二要素認証を有効化せずにアプリを配信したりすることが含まれます。

owasp.org原文

Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing.

Android/iOSアプリ開発に関連ある技術

開発ソース・モード切り替え

Android/iOSアプリに関する脆弱性の確認方法と対策

 開発環境へのコード(開発環境へのBasic認証とかログ出力)がないかを確認

お役に立てれば幸いです。