MASTG-TEST-0065 ネットワーク上のデータ暗号化のテスト (Testing Data Encryption on the Network)

概要

提示されたすべてのケースは全体として注意深く解析しなければなりません。たとえば、アプリが Info.plist でクリアテキストトラフィックを許可していないとしても、実際にはまだ HTTP トラフィックを送信している可能性があります。これは低レベルの API を使用している (ATS が無視される) 場合や、不適切に設定されたクロスプラットフォームフレームワークを使用している場合に当てはまります。

重要: これらのテストはアプリのメインコードだけでなく、アプリ内に組み込まれたアプリの拡張機能、フレームワーク、Watch アプリにも適用すべきです。

詳細については Apple Developer ドキュメントの記事 "Preventing Insecure Network Connections" および "Fine-tune your App Transport Security settings" を参照してください。

静的解析

セキュアプロトコルでのネットワークリクエストのテスト

まず、ソースコードのすべてのネットワークリクエストを特定し、プレーンな HTTP URL が使用されていないことを確認します。URLSession (標準の iOS の URL Loading System を使用する) または Network (TLS を使用して TCP および UDP にアクセスするソケットレベル通信) を使用して、機密情報がセキュアチャネルで送信されることを確認します。

低レベルネットワーク API の使用状況のチェック

アプリが使用するネットワーク API を特定し、低レベルネットワーク API を使用しているかどうかを確認します。

Apple の推奨事項: アプリでは高レベルフレームワークを優先すること: 「ATS はアプリが Network フレームワークや CFNetwork などの低レベルネットワークインタフェースに対して行う呼び出しには適用されません。これらの場合、接続のセキュリティを確保するのはあなたの責任です。この方法でセキュア接続を構築できますが、ミスを犯しやすく、コストもかかります。代わりに Loading System を使用するのが通常はもっとも安全です (出典 を参照) 。」

アプリが Network や CFNetwork などの低レベル API を使用している場合、それらがセキュアに使用されているかどうかを注意深く調査すべきです。クロスプラットフォームフレームワーク (Flutter, Xamarin など) やサードパーティフレームワーク (Alamofire など) を使用するアプリでは、それらがベストプラクティスに沿ってセキュアに設定され使用されているかどうかを解析すべきです。

アプリについて以下を確認します。

  • サーバー信頼性評価の実行時にチャレンジタイプとホスト名と資格情報を検証している。

  • TLS エラーを無視していない。

  • セキュアでない TLS 設定を使用していない (TLS 設定のテスト (Testing the TLS Settings) を参照)

これらのチェックは方向性を示すものであり、アプリごとに異なるフレームワークを使用している可能性があるため、特定の API を挙げることはできません。コードを調査する際の参考情報としてください。

クリアテキストトラフィックのテスト

アプリがクリアテキスト HTTP トラフィックを許可していないことを確認します。iOS 9.0 以降、クリアテキスト HTTP トラフィックはデフォルトで (App Transport Security (ATS) により) ブロックされますが、アプリケーションがそれを送信できる方法はいくつかあります。

  • アプリの Info.plist にある NSAppTransportSecurity で NSAllowsArbitraryLoads 属性を true (または YES) にセットしてクリアテキストトラフィックを有効にするよう ATS を設定する。

  • Info.plist を取得する (アプリパッケージの調査 (Exploring the App Package) を参照)

  • どのドメインでも NSAllowsArbitraryLoads がグローバルに true にセットされていないことをチェックする。

  • アプリケーションがサードパーティのウェブサイトを WebView で開く際、iOS 10 以降では NSAllowsArbitraryLoadsInWebContent を使用して WebView にロードされるコンテンツの ATS 制限を無効にできる。

Apple の警告: ATS を無効にすると、セキュアではない HTTP 接続が許可されます。HTTPS 接続も許可され、依然としてデフォルトのサーバー信頼性評価の対象となります。しかし、最低限の Transport Layer Security (TLS) プロトコルを要求するなどの拡張セキュリティチェックは無効になります。ATS を使用しない場合、 "Performing Manual Server Trust Authentication" で説明されているように、デフォルトのサーバー信頼性要件を自由に緩めることもできます。

以下のスニペットは ATS 制限をグローバルに無効化するアプリの 脆弱な例 を示しています。

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

ATS はアプリケーションのコンテキストを考慮して検討すべきです。アプリケーションはその意図する目的を達するために ATS 例外を定義する 必要がある かもしれません。たとえば、 Firefox iOS アプリケーションはグローバルに ATS を無効にしています 。この例外は受け入れられます。そうしないと、すべての ATS 要件を満たしていない HTTP ウェブサイトに接続できなくなるためです。場合によっては、アプリはグローバルに ATS を無効にするかもしれませんが、例えば、メタデータをセキュアにロードしたり、セキュアログインを可能にするため、特定のドメインでは有効にすることがあります。

ATS にはこれを 正当化する文字列 が含まれているべきです (例: 「このアプリはセキュアな接続をサポートしてない別のエンティティで管理されているサーバーに接続しなければなりません」) 。

動的解析

テスト対象のアプリの送受信ネットワークトラフィックを傍受して、このトラフィックが暗号化されていることを確認します。以下のいずれかの方法でネットワークトラフィックを傍受できます。

  • ZAP や Burp Suite などの傍受プロキシですべての HTTP(S) と Websocket トラフィックをキャプチャして、すべてのリクエストが HTTP ではなく HTTPS 経由で行われることを確認します。

  • Burp や ZAP などの傍受プロキシは、主にウェブ関連のトラフィック (HTTP(S), Web Sockets, gRPC など) を表示します。ただし、Burp-non-HTTP-Extension などの Burp プラグインや mitm-relay というツールを使用して XMPP や他のプトロコルを介した通信をデコードして可視化できます。

一部のアプリケーションでは証明書ピン留めが原因で Burp や ZAP などのプロキシで動作しないことがあります。そのようなシナリオでは カスタム証明書ストアおよび証明書ピン留めのテスト (Testing Custom Certificate Stores and Certificate Pinning) を確認してください。

詳細については以下を参照してください。

PreviousMASVS-NETWORK: ネットワーク通信NextMASTG-TEST-0066 TLS 設定のテスト (Testing the TLS Settings)

Last updated

Was this helpful?