クリアテキスト通信

OWASP カテゴリ: MASVS-NETWORK: ネットワーク通信

概要

Android アプリでクリアテキスト ネットワーク通信を許可すると、ネットワーク トラフィックを監視しているすべてのユーザーが、送信中のデータを表示して操作できるようになります。これは、送信されたデータにパスワード、クレジット カード番号、その他の個人情報などの機密情報が含まれている場合、脆弱性につながります。

機密情報を送信しているかどうかにかかわらず、クリアテキストを使用すると脆弱性が生じる可能性があります。クリアテキスト トラフィックは、ARP や DNS ポイズニングなどのネットワーク攻撃によっても操作されるため、攻撃者がアプリの動作に影響を与える可能性があります。

影響

Android アプリがネットワーク経由でクリアテキストでデータを送受信すると、ネットワークを監視しているすべての人がそのデータを傍受して読み取れるようになります。このデータにパスワード、クレジット カード番号、個人メッセージなどの機密情報が含まれている場合、個人情報の盗難や金融詐欺などの重大な問題につながる可能性があります。

たとえば、アプリがクリアテキストでパスワードを送信すると、悪意のあるトラフィック傍受者に機密情報が漏洩する可能性があります。漏洩したデータは、ユーザーのアカウントへの不正アクセスに利用される可能性があります。

リスク: 暗号化されていない通信チャネル

暗号化されていない通信チャネルを介してデータを送信すると、デバイスとアプリケーション エンドポイント間で共有されるデータが公開されます。これらのデータは攻撃者によって傍受され、改ざんされる可能性があります。

リスクの軽減

データは暗号化された通信チャネル経由で送信する必要があります。暗号化機能を提供しないプロトコルの代替として、安全なプロトコルを使用する必要があります。

特定のリスク

このセクションでは、標準的でない軽減戦略が必要、または特定の SDK レベルで軽減されたリスクをまとめています。また、完全を期すためにその他のリスクも挙げています。

リスク: HTTP

このセクションのガイダンスは、Android 8.1（API レベル 27）以前を対象とするアプリにのみ適用されます。Android 9（API レベル 28）以降、URLConnection、Cronet、OkHttp などの HTTP クライアントでは HTTPS の使用が強制されるため、クリアテキストのサポートはデフォルトで無効になっています。ただし、Ktor などの他の HTTP クライアント ライブラリでは、これらの制限がクリアテキストに適用される可能性は低いため、使用する際は注意が必要です。

リスクの軽減

NetworkSecurityConfig.xml 機能を使用して、クリアテキスト トラフィックをオプトアウトし、アプリに HTTPS を適用します。必要な特定のドメイン（通常はデバッグ目的）のみを例外とします。

XML

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

このオプションにより、バックエンド サーバーなどの外部ソースが提供する URL の変更によって、アプリで思わぬパフォーマンスの低下が発生するのを防ぐことができます。

リスク: FTP

FTP プロトコルを使用してデバイス間でファイルを交換すると、いくつかのリスクが発生します。最も重要なリスクは、通信チャネルでの暗号化の欠如です。代わりに、SFTP や HTTPS などの安全な代替手段を使用してください。

リスクの軽減

アプリケーションにインターネット経由のデータ交換メカニズムを実装する場合は、HTTPS などの安全なプロトコルを使用する必要があります。Android には、デベロッパーがクライアント サーバー ロジックを作成できる一連の API が用意されています。これは Transport Layer Security（TLS）を使用して保護できます。これにより、2 つのエンドポイント間でのデータ交換が暗号化され、悪意のあるユーザーが通信を傍受して機密データを取得するのを防ぐことができます。

通常、クライアント サーバー アーキテクチャは、デベロッパー所有の API に依存しています。アプリケーションが一連の API エンドポイントに依存している場合は、HTTPS 通信を保護するための次のセキュリティのベスト プラクティスに従って、多層セキュリティを確保します。

  • 認証 - ユーザーは OAuth 2.0 などの安全なメカニズムを使用して認証する必要があります。通常、Basic 認証は推奨されません。これは、セッション管理メカニズムを提供しないためです。認証情報が不適切に保存されている場合、Base64 からデコードされる可能性があります。
  • 認可 - 最小権限の原則に従って、ユーザーが目的のリソースのみにアクセスできるようにする必要があります。これは、アプリケーションのアセットに慎重なアクセス制御ソリューションを採用することで実装できます。
  • セキュリティのベスト プラクティスに沿って、最新の暗号スイートが使用されていることを確認します。たとえば、HTTPS 通信で、必要に応じて下位互換性のある TLSv1.3 プロトコルをサポートすることを検討してください。

リスク: カスタム通信プロトコル

カスタム通信プロトコルを実装したり、既知のプロトコルを手動で実装しようとしたりすると、危険な場合があります。

カスタム プロトコルを使用すると、デベロッパーは目的のニーズに合わせて独自のソリューションを調整できますが、開発プロセス中にエラーが発生すると、セキュリティ上の脆弱性が生じる可能性があります。たとえば、セッション処理メカニズムの開発でエラーが発生すると、攻撃者が通信を盗聴し、機密情報をその場で取得できる可能性があります。

一方、OS やメンテナンスが行き届いたサードパーティ製ライブラリを使用せずに、HTTPS などのよく知られたプロトコルを実装すると、コーディング エラーが発生する可能性が高まり、必要に応じて実装したプロトコルを更新するのが困難になる可能性があります。また、カスタム プロトコルを使用する場合と同じ種類のセキュリティ上の脆弱性が生じる可能性があります。

リスクの軽減

維持されているライブラリを使用して、よく知られた通信プロトコルを実装する

HTTPS などのよく知られたプロトコルをアプリケーションに実装するには、OS ライブラリまたは保守されているサードパーティ ライブラリを使用する必要があります。

これにより、デベロッパーは、入念にテストされ、時間の経過とともに改善され、一般的な脆弱性を修正するためのセキュリティ アップデートを継続的に受信しているソリューションを選択できます。

さらに、よく知られたプロトコルを選択することで、さまざまなシステム、プラットフォーム、IDE と幅広い互換性が得られるため、開発プロセス中にヒューマン エラーが発生する可能性が低くなります。

SFTP を使用する

このプロトコルでは、転送中のデータが暗号化されます。この種のファイル交換プロトコルを使用する場合は、追加の手段を考慮する必要があります。

  • SFTP はさまざまな種類の認証をサポートしています。パスワードベースの認証ではなく、公開鍵認証方法を使用する必要があります。このような鍵は安全に作成、保存する必要があります。このためには、Android Keystore をおすすめします。
  • サポートされている暗号がセキュリティのベスト プラクティスに準拠していることを確認します。

リソース