ネットワーク通信のテスト
Last updated
Was this helpful?
Last updated
Was this helpful?
ネットワークに接続されたほとんどすべてのモバイルアプリは、リモートエンドポイントとデータを交換するために、Hypertext Transfer Protocol (HTTP) またはその安全なバージョンである HTTPS (Transport Layer Security, TLS を使用) に依存しています。安全に実装されていない場合、この通信はパケットスニッフィングや中間マシン (Machine-in-the-Middle, MITM) 攻撃などのネットワークベースの攻撃に対して脆弱になる可能性があります。この章では、潜在的な脆弱性、テスト技法、モバイルアプリのネットワーク通信を保護するためのベストプラクティスについて説明します。
平文の HTTP を単独で使用することが合理的であった時代は過ぎ去り、HTTPS を使用して HTTP 接続を保護することは一般的にありふれたものとなりました。HTTPS は基本的に Transport Layer Security (TLS) と呼ばれる別のプロトコルの上に HTTP を重ねたものです。そして TLS は公開鍵暗号を使用してハンドシェイクを実行し、セキュア接続を作成します。
HTTPS 接続は以下の三つの性質によってセキュアであると考えられています。
機密性 (Confidentiality): TLS はネットワーク上に送信する前にデータを暗号化するため、仲介者が読み取ることはできません。
完全性 (Integrity): 検出されずにデータを改変することはできません。
認証 (Authentication): クライアントはサーバーの同一性を検証して、正しいサーバーとの接続を確立していることを確認できます。
認証局 (Certificate Authority, CA) はセキュアなクライアントサーバー通信に不可欠な要素であり、各オペレーティングシステムのトラストストアにあらかじめ定義されています。たとえば、iOS では 200 のルート証明書がインストールされています ( を参照ください) 。
CA はユーザーが手動で、エンタープライズデバイスを管理する MDM によって、またはマルウェアを介して、トラストストアに追加できます。問題は「これらの CA をすべて信頼でき、アプリはデフォルトトラストストアに依存すべきか？」ということです。結局のところ、認証局が侵害されたり、騙されて偽物に証明書を発行するケースはよく知られています。CA の侵害や不備の詳細なタイムラインが にあります。
Android と iOS のいずれもユーザーが追加の CA やトラストアンカーをインストールできます。
アプリはプラットフォームのデフォルトではなく、CA のカスタムセットを信頼したいことがあります。これについて最も一般的な理由は以下のとおりです。
自己署名された認証局や会社内で発行された認証局など、カスタム認証局 (システムでまだ認識または信頼されていない CA) でホストに接続すること。
CA のセットを特定の信頼できる CA のリストに限定すること。
システムに含まれていない追加の CA を信頼すること。
アプリが自己署名証明書やシステムにとって未知の証明書を持つサーバーに接続すると、セキュア接続は失敗します。これは一般的にたとえば政府、企業、教育機関などの組織が独自に発行するような非公開 CA の場合に当てはまります。
Android と iOS のいずれも信頼を拡張する手段を提供しています。つまり、アプリがシステムにビルトインされているものとカスタムのものを信頼するように、追加の CA を組み込めます。
しかし、デバイスユーザーは常に追加の CA を組み込めることを忘れないでください。したがって、アプリの脅威モデルによってはユーザートラストストアに追加されたすべての証明書を信頼しない、あるいはあらかじめ定義された特定の証明書または証明書セットのみを信頼することが必要な場合があります。
多くのアプリでは、モバイルプラットフォームが提供する「デフォルトの動作」がユースケースに対して十分セキュアです (システムが信頼する CA が侵害されるようなまれなケースでは、アプリが扱うデータは機密とはみなされないか、CA 侵害などに耐性がある他のセキュリティ対策がとられます) 。しかし、金融や医療アプリなどの他のアプリでは、たとえまれなケースであっても CA 侵害のリスクを考慮しなければなりません。
アプリによっては信頼する CA の数を制限することでセキュリティをさらに高める必要があるかもしれません。一般的には開発者が使用する CA のみを明示的に信頼し、その他はすべて無視します。この信頼の制限は 同一性ピンニング (Identity Pinning) と呼ばれ、通常は 証明書ピンニング (Certificate Pinning) や 公開鍵ピンニング (Public Key Pinning) として実装されます。
OWASP MASTG ではこの用語を "同一性ピンニング (Identity Pinning)", "証明書ピンニング (Certificate Pinning)", "公開鍵ピンニング (Public Key Pinning)" あるいは単に "ピンニング (Pinning)" と呼びます。
ピンニングとは信頼された CA によって署名された任意の証明書を受け入れる代わりに、X.509 証明書や公開鍵などの特定の同一性とリモートエンドポイントを関連付けるプロセスです。サーバー同一性 (または特定のセット、別名 pinset) をピン留めすると、その後モバイルアプリはその同一性が一致した場合にのみそれらのリモートエンドポイントに接続します。不要な ＣＡ から信頼を取り除くことで、アプリの攻撃対象領域が減少します。
ピンニングを推奨する場合と例外を適用する可能性がある場合。
ピン留めする時期: 開発時 (プリロード) または初回遭遇時 (初回使用時の信頼) 。
ピン留めするもの: 証明書、公開鍵、ハッシュ。
Android と iOS の推奨事項はどちらも以下の「ベストケース」と合致しています。
開発者がコントロールできるエンドポイントにのみピン留めする。
開発時に (NSC/ATS) 経由で。
SPKI subjectPublicKeyInfo のハッシュをピン留めする。
数年前に導入されて以来、ピンニングには悪い評判が広まっています。少なくともモバイルアプリケーションのセキュリティに有効なポイントをいくつか明らかにしたいと思います。
評判が悪いのはセキュリティの欠如ではなく、運用上の理由 (実装やピン管理の複雑さなど) によるものです。
アプリがピンニングを実装していない場合、これは脆弱性として報告すべきではありません。ただし、MASVS-L2 に対する検証を行わなければならない場合には実装しなければなりません。
Android と iOS のいずれもピンニングの実装は非常に簡単であり、ベストプラクティスに沿っています。
ピンニングはデバイスにインストールされている侵害された CA や悪意のある CA から保護します。そのようなケースでは、ピンニングは OS が悪意のあるサーバーとセキュア接続を確立することを防ぎます。しかし、攻撃者がデバイスをコントロールしている場合、簡単にピンニングロジックを無効して、接続を行うことが依然として可能です。結果として、攻撃者がバックエンドにアクセスして、サーバー側の脆弱性を悪用することを防ぐことはできません。
モバイルアプリのピンニングは HTTP Public Key Pinning (HPKP) と同じではありません。HPKP ヘッダはユーザーがウェブサイトからロックアウトされ、ロックアウトを解除する方法がないことから、ウェブサイトでは推奨されなくなりました。モバイルアプリでは、なんらかの問題があっても帯域外チャネル (つまりアプリストア) を通じて常にアプリを更新できるため、これは問題ではありません。
注意: 証明書ピンニングは別の認証局に変更するなどの将来的なサーバー構成の変更により、クライアントソフトウェアの更新を受けることなくアプリケーションがサーバーに接続できなくなるリスクが高いため、Android アプリケーションには推奨されません。
証明書のピン留めを使用するときは、必ずバックアップの鍵を含めてください。そうすれば、新しい鍵に切り替えたり、CA を変更したりする必要が生じた場合に（CA 証明書またはその CA の中間証明書にピン留めしていても）、アプリの接続が影響を受けることはありません。そうしないと、接続を復元するためにアプリにアップデートをプッシュしなければならなくなります。
最初の文は「証明書ピンニングを推奨しない」と言っているものと誤解される可能性があります。二つ目の文でこれを明らかにしています。実際の推奨事項は、開発者がピンニングを実装したい場合には必要な予防措置を講じなければならない、ということです。
特に MASVS-L2 アプリで、ピンニングをお勧めします。ただし、開発者は自分の管理下にあるエンドポイントに限定して実装し、バックアップ鍵 (別名、バックアップピン) を含めるようにし、適切なアプリ更新戦略を持つようにしなければなりません。
コアとなるモバイルアプリの機能のひとつはインターネットなどの信頼できないネットワーク上でデータを送受信することです。データが転送中に正しく保護されない場合、ネットワークインフラストラクチャの任意の部分 (Wi-Fi アクセスポイントなど) にアクセスできる攻撃者は、傍受、読み取り、改変の可能性があります。これが平文のネットワークプロトコルがほとんど推奨されない理由です。
大部分のアプリはバックエンドとの通信に HTTP に依存しています。HTTPS は暗号化された接続で HTTP をラップします (略語の HTTPS はもともと HTTP over Secure Socket Layer (SSL) と呼ばれていました。SSL は TLS の前身で非推奨です) 。TLS はバックエンドサービスの認証を可能にし、ネットワークデータの機密性と完全性を保証します。
モバイルアプリケーションが特定のサーバーに接続している場合、そのネットワークスタックを調整して、サーバーの構成に対して可能な限り高いセキュリティレベルを確保できます。基盤となるオペレーティングシステムのサポートがない場合、モバイルアプリケーションがより脆弱な構成を使用するように強制する可能性があります。
暗号スイートの構造は以下の通りです。
この構造は以下のとおりです。
プロトコル は暗号に使用されます
鍵交換アルゴリズム は TLS ハンドシェイク時の認証にサーバーおよびクライアントで使用されます
ブロック暗号 はメッセージストリームを暗号化するために使用されます
完全性チェックアルゴリズム はメッセージを認証するために使用されます
例: TLS_RSA_WITH_3DES_EDE_CBC_SHA
上記の例では暗号スイートは以下のものを使用します。
TLS をプロトコルとして
RSA を認証用の非対称暗号に
3DES を EDE_CBC モードで対称暗号用に
SHA を完全性用のハッシュアルゴリズムに
TLSv1.3 では鍵交換アルゴリズムは暗号スイートの一部ではなく、代わりに TLS ハンドシェイク時に決定されることに注意します。
以下のリストでは、暗号スイートの各部分のさまざまなアルゴリズムについて説明します。
プロトコル:
SSLv1
鍵交換アルゴリズム:
ブロック暗号:
完全性チェックアルゴリズム:
暗号スイートの性能はそのアルゴリズムの性能に依存することに注意します。
以下のリソースには TLS で使用する最新の推奨暗号スイートがあります。
サーバーが正しい暗号スイートをサポートしているかどうかを検証したい場合、さまざまなツールを使用できます。
この技法には二つの側面があります。
通常、どちらの当事者 (アプリまたはサーバー) に気付かれることなく通信を傍受、監視、潜在的に改変するために 悪意のある攻撃者によって使用されます。これは、盗聴、悪意のあるコンテンツの注入、交換されるデータの操作などの悪意のあるアクティビティを可能にします。
しかし、OWASP MASTG とモバイルアプリセキュリティテスト のコンテキストでは、アプリテスト担当者がトラフィックをレビュー、解析、変更するための技法の一部として使用し、暗号化されていない通信や弱いセキュリティコントロールなどの脆弱性を特定できます。
使用される具体的な傍受方法はアプリのセキュリティメカニズムと送信されるデータの性質によって異なります。各アプローチは、暗号化や、妨害に対する耐性などの要素に応じて、複雑さや有効性が異なります。
さまざまなネットワーク層での傍受技法の概要は以下のとおりです。
傍受技法
ツール例
備考
API フック (HttpUrlConnection, NSURLSession, WebRequest)
Frida
アプリがネットワークリクエストを処理する方法を変更します。
TLS 関数のフック (SSL_read, SSL_write)
Frida, SSL Kill Switch
暗号化データがアプリに到達する前に傍受します。
プロキシ傍受
Burp Suite, ZAP, mitmproxy
アプリがプロキシ設定を尊重する必要があります。
パケットスニッフィング
tcpdump, Wireshark
すべての TCP/UDP をキャプチャしますが HTTPS を復号 しません。
ARP スプーフィングによる MITM
bettercap
ネットワークが攻撃者によって制御されていない場合でも、デバイスを騙して攻撃者のマシン経由でトラフィックを送信します。
不正な Wi-Fi AP
hostapd, dnsmasq, iptables, wpa_supplicant, airmon-ng
攻撃者によって完全に制御されているアクセスポイントを使用します。
これらの技法の詳細については、それぞれの技法のページにあります。
証明書ピン留めに関する注意: アプリが証明書ピン留めを使用している場合、トラフィックの傍受を開始すると上記の技法は失敗するように見えるかもしれませんが、別の手法を使用してバイパスできます。詳細については以下の技法を参照してください。
では以下のような重要なガイダンスを提供しています。
サイトには以下の警告が記されています。
またこのような もあります。
Apple は と を推奨しています。
サーバー側で適切な TLS 設定を確保することも重要です。SSL プロトコルは非推奨であり、もはや使用すべきではありません。 また TLS v1.0 および TLS v1.1 には があり、2020年までにすべての主要なブラウザでその使用が非推奨になりました。 TLS v1.2 および TLS v1.3 はデータのセキュアな送信のためのベストプラクティスとみなされています。Android 10 (API level 29) 以降 TLS v1.3 はより高速でセキュアな通信のためにデフォルトで有効になります。 は暗号スイートのカスタマイズができなくなること、および TLS v1.3 が有効である場合にはそれらすべてが有効になることです。一方、ゼロラウンドトリップ (0-RTT) モードはサポートされません。
クライアントとサーバーの両方が同じ組織により制御され、互いに通信するためだけに使用される場合、 によりセキュリティを向上できます。
SSLv2 -
SSLv3 -
TLSv1.0 -
TLSv1.1 -
TLSv1.2 -
TLSv1.3 -
DSA -
ECDSA -
RSA -
DHE - -
ECDHE -
PSK -
DSS -
DH_anon - -
DHE_RSA - -
DHE_DSS - -
ECDHE_ECDSA -
ECDHE_PSK - -
ECDHE_RSA -
DES -
DES_CBC -
3DES -
3DES_EDE_CBC -
AES_128_CBC -
AES_128_GCM -
AES_256_CBC -
AES_256_GCM -
RC4_40 -
RC4_128 -
CHACHA20_POLY1305 - -
MD5 -
SHA -
SHA256 -
SHA384 -
IANA 推奨暗号スイートは にあります。
OWASP 推奨暗号スイートは にあります。
一部の Android および iOS バージョンは推奨暗号スイートの一部をサポートしていないため、互換性を保つために および バージョンでサポートされている暗号スイートを確認し、サポートされている上位の暗号スイートを選択します。
nscurl - 詳細については を参照してください。
は「TLS/SSL 暗号、プロトコルのサポートおよび一部の暗号の欠陥について、任意のポート上のサーバーのサービスをチェックするフリーのコマンドラインツールです。」
最後に、HTTPS 接続が終了するサーバーや終端プロキシがベストプラクティスにしたがって構成されていることを検証します。 および も参照してください。
モバイルアプリのトラフィックを傍受することはセキュリティテストの側面であり、テスト担当者、アナリスト、ペネトレーションテスト担当者がネットワーク通信を解析および操作して脆弱性を特定できるようにします。このプロセスで重要な技法は 中間マシン (Machine-in-the-Middle, MITM) 攻撃 ( (従来)、"中間敵対者 (Adversary-in-the-Middle)" ( や などによる) とも呼ばれます) です。攻撃者 は自分のマシンを二つの通信エンティティ、通常はモバイルアプリ (クライアント) とそれが通信するサーバー、の間に配置します。そうすることで、攻撃者のマシンはさまざまな当事者間で送信されるデータを傍受して監視します。
Android:
iOS: