クリアテキスト通信

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 などの安全なメカニズム を使用して認証する必要があります。基本認証は、セッション管理メカニズムを提供せず、認証情報が適切に保存されていない場合は Base64 からデコードできるため、通常は推奨されません。
  • 認可 - ユーザーは、最小権限の原則に従って、意図したリソースにのみアクセスできるように制限する必要があります。これは、アプリケーションのアセットに対して慎重なアクセス制御ソリューションを採用することで実装できます。
  • セキュリティに関するおすすめの方法に沿って、慎重に検討された最新の暗号スイートを使用してください。たとえば、HTTPS 通信で TLSv1.3 プロトコル を後方互換性でサポートすることを検討してください。

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

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

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

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

リスクの軽減

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

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

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

また、よく知られているプロトコルを選択することで、デベロッパーはさまざまなシステム、プラットフォーム、IDE での幅広い互換性のメリットを享受し、開発プロセスでの人的エラーの可能性を減らすことができます。

SFTP を使用する

このプロトコルは、転送中のデータを暗号化します。この種のファイル交換プロトコルを使用する場合は、次の追加の対策を講じる必要があります。

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

リソース