AndroidMで追加された、クリアテキスト機能について
Google Developer Blogの方で先日、「Protecting against unintentional regressions to cleartext traffic in your Android apps」という記事が投稿されました。セキュリティに関する事ですので、翻訳をしました。要約すると、Android N のNetwork Security Config機能でこのあたりまた拡張されるのですが、Android Mでも平文通信を禁止するクリアテキスト機能は使用可能で、サードパーティのライブラリ等は影響うけるからそろそろ対応してね。という感じです。
クリアテキストという用語はあまり聞きなれない用語になりますが、「平文」と置き換えるのが一番いいと思います。クリアテキスト通信→平文通信となります。
検証等、動作確認はしていませんが、以下翻訳(超訳?)です。興味がある方は参照ください。
Protecting against unintentional regressions to cleartext traffic in your Android apps
あなたのアプリケーションがHTTPのようなクリアテキスト(平文)ネットワーク通信でサーバと送受信する時、第三者によって盗聴や改ざんされるリスクがあります。
これは、ユーザ情報の漏えいや、アプリが不正なコンテンツや、エクスプロイトをインジェクションされ開いてしまう可能性を表します。
理想的には、アプリケーションは、HTTPの代わりにHTTPSを使うなどの安全な通信のみをすべきです。このような通信は、盗聴や改ざんから守られます。
多くのアンドロイドアプリは既に安全な通信のみ使用しています。しかしながら、それらのいくつかは、時折事故によって通信をクリアテキスト(平文)で行ってしまいます。
(訳注:事故じゃなくても平文で送っているアプリもまだまだありますが…)
例えば、サーバーコンポーネントの不注意な変更で、サーバがアプリケーションにHTTPSのURLの代わりにHTTPのURLを提供する事があります。(訳注:サーバがクライアントに次にクライアントからアクセスするURLを返すような仕様の場合)
アプリケーションは、クリアテキスト(平文)で通信を続け、しかもそれはユーザにはわかりません。このような状況はアプリ開発者もユーザも気が付かないことがあります。
アプリがセキュアな通信のみしていると信じていても、偶発的な問題をキャッチし防止するために、Android Marshmalow(Android 6.0)で導入された新しい機能を使用してください。(訳注:NじゃなくてMで導入)
NEW PROTECT MECHANISMS
安全な通信のみ行いたいアプリケーションのために、Android 6.0 Marshmallow(API Level23)では、クリアテキストの二つの機能を導入しました。
(1) 製品用のクリアテキストブロック
(2) 開発、QA用の非TLS/SSL通信を行ったときにログに出力したり、クラッシュする機能
次のセクションでこれらの機能について詳しく説明をします
Block cleartext traffic in production
(製品用のAndroidManifetを用いたクリアテキストのブロック手法)
アプリでクリアテキスト通信(平文通信)をしないように保護するために、アプリケーションのAndroidManifest.xmlのapplicationエレメントにandroid:usesCleatextTraffic=”false”と宣言します。(訳注:デフォルトはtrue)
この宣言は、このアプリはクリアテキスト(平文)通信を使用する事が想定されていないことを意味し、Android Marshmallowのプラットフォームネットワークスタックがクリアテキストトラフィックをブロックします。
例えば、アプリが誤ってHTTPSの平文でユーザのサインインを使用とした時、そのリクエストはブロックされるので、ユーザのIDやパスワードはネットワーク上にリークされる事はありません。
アプリケーションのminSdkVersionやtargerSdkVersionを23(Android Marshmallow)にする必要はありません。古いプラットフォーム上でアプリが動作する時は単純にこの属性は無視されるのでなんの影響もありません。
WebViewはまだこの機能の影響を受けないので注意してください。(注:平文禁止設定してもWebViewでは平文通信可能)
その他、特定の状況下でクリアテキストトラフィックはアプリケーション内で発生します。
例えば、ソケットAPIはクリアテキストポリシーを無視します。なぜなら送信または受信したデータをクリアテキストとして分類することができないからです。
アンドロイドプラットフォームのHTTPスタックは、通信がクリアテキストかが分かるためクリアテキストポリシーが適用されます。
Google AdMobもこのポリシーを守るよう作成されています。
アプリがクリアテキストを使用しないと宣言をしたとき、HTTPSのみの広告をアプリケーションに提供します。
サードパーティのネットワーク、広告、や情報分析ライブラリは、このポリシーのサポートを追加することをお勧めします。
NetworkSecurityPolicyクラスを経由して、クリアテキスト通信のポリシーを取得することができます。(訳注:isCleartextTrafficPermittedを使って判別し切り替えます)
Detect cleartext traffic during development
(開発時のStrictModeを利用したクリアテキスト検知方法)
開発やQA中にクリアテキスト通信を発見するには、StrictMode APIを使い、非TLS/SSL通信を見つけ、システムログに違反を記録したり、アプリをクラッシュさせたりする事ができます。(参照StrictMode.VmPolicy.Builder.detectCleartextNetwork())
これは、アプリケーションが非TLS/SSL通信を使用していることを識別する便利なツールです。
Android:usesCleartextTraffic属性とは異なり、この機能はユーザに配布する時は無効にします。
まずこの機能は、非TLS/SSL通信の検知をサポートします、さらに重要なことは、HTTP proxyを介したTLS/SSL通信も検出されるでしょう。開発者として特定のユーザがアンドロイド端末の設定をしてHTTP proxyを利用するかどうかをコントロールすることはできないため問題が発生します。
最後にこの機能の実装は将来的に保障されていません。今後のTLS/SSLプロトコルのバージョンを拒否するかもしれません。従って、この機能は開発中及びQAフェーズのみ宙に使用されることを意図しています。
(訳注:StrictModeのクリアテキスト判別の存在意義ってあまりない気がします)
Declare finger-grained cleartext policy in Network Security Config
(AndroidNでのクリアテキスト機能の拡張)
Android Nでは、クリアテキストトラフィックポリシーのより細かい制御を提供しています。アプリケーションが通信するすべての接続先に適用されるandroid:usesCleartextTraffic属性とは対照的に、Android NのNetwork Security Configは接続先別にクリアテキストを指定できます。
例えば、クリアテキスト(平文)通信を使用しない方針に、より緩やかな以降をするために、アプリは最も重要なバックエンドへの通信のみクリアテキストをブロックし、他の通信先にはクリアテキストを許可する事ができます。
NEXT STEP
アプリケーションとサーバの間にセキュアな通信を行うのはセキュリティのベストプラクティスです。Android Mashmallowはこのベストプラクティスを実現することができます。挑戦してみてね!(訳注:そういうなら、Googleさん、ちゃんともっと早く見つけやすい所で告知してね)