5. ネットワーク通信要件

5.1. MSTG-NETWORK-1

データはネットワーク上でTLSを使用して暗号化されている。セキュアチャネルがアプリ全体を通して一貫して使用されている。

5.1.1. 安全なネットワーク通信の設定

提示されたすべてのケースは、全体として慎重に分析する必要がある。例えば、アプリが Info.plist で平文トラフィックを許可していない場合でも、実際には HTTP トラフィックを送信している可能性がある。低レベルの API （ ATS が無視される）を使用している場合や、クロスプラットフォームフレームワークの構成が不十分な場合は、このようなケースになる可能性がある。

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

詳しくは、 Apple Developer Documentation の記事「 Preventing Insecure Network Connections 」と「 Fine-tune your App Transport Security settings 」を参照する。

参考資料

ルールブック

5.1.2. 静的解析

5.1.2.1. セキュアプロトコルでのネットワーク要求の検証

まず、ソースコードですべてのネットワーク要求を識別し、平文の HTTP URL が使用されていないことを確認する必要がある。 URLSession （ iOS の標準的な URL Loading System を使用）または Network （ TLS と TCP および UDP へのアクセスを使用したソケットレベルの通信用）を使用して、機密情報が安全なチャネルを介して送信されることを確認する。

参考資料

ルールブック

5.1.2.2. 低レベルのネットワーキング API の使用状況を確認

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

Apple の推奨：アプリに高レベルのフレームワークを優先する 「 ATS は、アプリケーションが Network framework や CFNetwork のように低レベルのネットワーキングインターフェースを呼び出す場合には適用されない。このような場合、接続のセキュリティを確保する責任は、ユーザ自身にある。この方法で安全な接続を構築することはできるが、間違いが起こりやすく、コストもかかる。代わりに URL Loading System に頼るのが一般的に最も安全である。」（ソース参照）

アプリが Network や CFNetwork などの低レベルの API を使用している場合、それらが安全に使用されているかどうかを慎重に調査する必要がある。クロスプラットフォームフレームワーク（ Flutter、Xamarin など）やサードパーティフレームワーク（ Alamofire など）を使用しているアプリの場合、それらがベストプラクティスに従って安全に設定され使用されているかどうかを分析する必要がある。

アプリを確認する：

  • サーバの信頼性評価を行う際に、チャレンジの種類とホスト名および認証情報を検証する。

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

  • 安全でない TLS 設定を使用していない。（「 TLS 設定の検証（ MSTG-NETWORK-2 ）」を参照）

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

参考資料

ルールブック

5.1.2.3. 平文トラフィックの検証

アプリが平文の HTTP トラフィックを許可していないことを確認する。 iOS 9.0 以降では、平文の HTTP トラフィックはデフォルトでブロックされる（ App Transport Security（ ATS ）による）が、アプリケーションが平文の HTTP を送信する方法は複数存在する。

  • アプリの Info.plist にある NSAppTransportSecurity の NSAllowsArbitraryLoads 属性を true （または YES ）に設定し、 ATS が平文トラフィックを有効にするように設定する。

  • Info.plist を取得する

  • NSAllowsArbitraryLoads が、どのドメインでも、グローバルで true に設定されていないことを確認する。

  • アプリケーションが WebView でサードパーティの Web サイトを開く場合、 iOS 10 以降、 NSAllowsArbitraryLoadsInWebContent を使用すると、 WebView に読み込まれるコンテンツの ATS 制限を無効にすることができる。

Appleの警告： ATS を無効にすると、安全でないHTTP接続が許可される。HTTPS 接続も許可され、デフォルトのサーバ信頼性評価が適用される。ただし、TLS（ Transport Layer Security ）プロトコルの最低バージョンを要求するなどの拡張セキュリティチェックは無効となる。 ATS を使用しない場合、「手動サーバ信頼性認証の実行」で説明するように、デフォルトのサーバ信頼性要件を自由に緩和することもできる。

以下のスニペットは、アプリが ATS の制限をグローバルに無効化する脆弱性のある例である。

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

ATS は、アプリケーションのコンテキストを考慮して検討する必要がある。アプリケーションは、その意図する目的を果たすために、 ATS の例外を定義する場合がある。例えば、 Firefox の iOS アプリケーションは、グローバルに ATS を無効にしている。そうでなければ、 ATS の要件をすべて満たしていない HTTP ウェブサイトに接続できないため、この例外は許容される。場合によっては、アプリケーションはグローバルに ATS を無効にするが、特定のドメインではメタデータを安全に読み込んだり、安全なログインを可能にするなどの目的で有効にすることがある。

ATS は、このための正当な理由を示す記述を含める必要がある。（例：「このアプリは、安全な接続をサポートしない別のエンティティによって管理されるサーバに接続する必要がある」）

参考資料

ルールブック

5.1.3. 動的解析

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

  • OWASP ZAP や Burp Suite のようなインターセプションプロキシですべての HTTP(S) と Websocket のトラフィックを取得し、すべての要求が HTTP ではなく HTTPS で行われることを確認する。

  • Burp や OWASP ZAP のようなインターセプションプロキシは、 HTTP(S) トラフィックのみを表示する。しかし、Burp-non-HTTP-Extension などの Burp プラグインや mitm-relay というツールを使えば、 XMPP やその他のプロトコルによる通信をデコードして可視化することが可能である。

一部のアプリケーションは、証明書のピン留めにより、Burp や OWASP ZAP のようなプロキシで動作しない場合があります。そのような場合は、「Testing Custom Certificate Stores and Certificate Pinning 」を確認すること。

詳細は以下参照：

参考資料

ルールブック

5.1.4. ルールブック

  1. App Transport Security (ATS) を使用する（必須）

  2. URLSession を使用する（推奨）

  3. CFNetwork を使用する （非推奨）

  4. Network Framework を使用する（推奨）

  5. 低レベルのネットワーキング API はベストプラクティスに従って安全に使用する（必須）

5.1.4.1. App Transport Security (ATS) を使用する （必須）

ATS では、すべての HTTP 接続に HTTPS を使用する必要がある。さらに、Transport Layer Security ( TLS ) プロトコルによって規定されたデフォルトのサーバ信頼評価を補完する拡張セキュリティチェックを課す。ATS は、最低限のセキュリティ仕様を満たさない接続をブロックする。

アプリケーション内で利用されているデータを可能な限りセキュアにするために、現時点でセキュアでない接続をしているのかどうかをまず把握することが重要である。

その確認のため、アクティブな ATS の例外をすべて無効にするために Info.plist の App Transport Security Settings の Allow Arbitrary Loads 属性に「 NO 」を設定する。アプリケーションがセキュアでない接続を行った場合、それぞれの接続に対し Xcode 上でランタイムエラーが発生する。

ATS が有効になるのは以下の場合である。

  • Info.plist に App Transport Security Settings が未指定の場合。

  • Info.plist で、Allow Arbitrary Loads 属性、Allows Arbitrary Loads for Media 属性、Allows Arbitrary Loads in Web Content 属性、NSExceptionAllowsInsecureHTTPLoads 属性に NO が指定され、NSExceptionRequiresForwardSecrecy 属性に YES が指定され、NSExceptionMinimumTLSVersion に 1.2 以上が指定されている場合。

Xcode上での info.plist 設定:

../_images/AllowsATS.jpeg

図 5.1.4.1.1 ATSで除外する例

これに違反する場合、以下の可能性がある。

  • セキュリティ仕様を満たさない接続を実施する可能性がある。

5.1.4.2. URLSession を使用する（推奨）

URL を操作し、標準のインターネットプロトコルを使用してサーバと通信するために、 iOS には URL Loading System が用意されている。 これを利用するために URLSession を使用する。

import UIKit

class Fetch {
    func getDataAPI(completion: @escaping (Any) -> Void) {
        let requestUrl = URL(string: "http://xxxxx")!
	    // URLSessionのdatataskを使い、data取得。
        let task = URLSession.shared.dataTask(with: requestUrl) { data, response, error in
	        // エラーが返ってきたときの処理。
            if let error = error {
                completion(error)
            } else if let data = data {
                completion(data)
            }
        }
        task.resume()
    }
}

これに注意しない場合、以下の可能性がある。

  • 機密情報が安全ではないチャネルを介して送信される可能性がある。

5.1.4.3. CFNetwork を使用する （非推奨）

CFNetwork は、iOS 2.0 で用意された BSD ソケットの操作、HTTP および FTP サーバ通信を行うAPI。

現在はそのほとんどが非推奨になっている。 ATS を有効に機能させるためには URLSession （ iOS の標準的な URL Loading System を使用）を推奨する。

これが非推奨である理由は以下である。

  • 機密情報が安全ではないチャネルを介して送信される可能性がある。

5.1.4.4. Network Framework を使用する（推奨）

TLS、TCP、UDP や独自のアプリケーションプロトコルに直接アクセスする必要がある場合に使用する。 HTTP ( S ) や URL ベースのリソースの読み込みの場合はこれまでと変わらず URLSession を使用する。

import Foundation
import Network

class NetworkUDP {
    // 定数
    let networkType = "_myApp._udp."
    let networkDomain = "local"

    private func startListener(name: String) {
        // usingに udp で listener を作成
        guard let listener = try? NWListener(using: .udp, on: 11111) else { fatalError() }

        listener.service = NWListener.Service(name: name, type: networkType)

        let listnerQueue = DispatchQueue(label: "com.myapp.queue.listener")

        // 新しいコネクション受診時の処理
        listener.newConnectionHandler = { [unowned self] (connection: NWConnection) in
            connection.start(queue: listnerQueue)
            self.receive(on: connection)
        }

        // Listener開始
        listener.start(queue: listnerQueue)

    }

    private func receive(on connection: NWConnection) {
        /* データ受信 */
        connection.receive(minimumIncompleteLength: 0,
                           maximumLength: 65535,
                           completion:{(data, context, flag, error) in
            if let error = error {
                NSLog("\(#function), \(error)")
            } else {
                if data != nil {
                    /* 受信データのデシリアライズ */
                    
                }
                else {
                    NSLog("receiveMessage data nil")
                }
            }
        })
    }

}

これに注意しない場合、以下の可能性がある。

  • 機密情報が安全ではないチャネルを介して送信される可能性がある。

5.1.4.5. 低レベルのネットワーキング API はベストプラクティスに従って安全に使用する（必須）

アプリが低レベルの API を使用している場合、それらが安全に使用されているかどうかを慎重に調査する必要がある。クロスプラットフォームフレームワーク（ Flutter、Xamarin など）やサードパーティフレームワーク（ Alamofire など）を使用しているアプリの場合、それらがベストプラクティスに従って安全に設定され使用されているかどうかを分析する必要がある。

アプリが以下に準拠していることを確認する：

  • サーバの信頼性評価を行う際に、チャレンジの種類とホスト名および認証情報を検証する。

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

  • 安全でない TLS 設定を使用していない。（「 TLS 設定の検証（ MSTG-NETWORK-2 ）」を参照）

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

これに違反する場合、以下の可能性がある。

  • アプリが安全性の低い通信を実施する可能性がある。

5.2. MSTG-NETWORK-2

TLS 設定は現在のベストプラクティスと一致している。モバイルオペレーティングシステムが推奨される標準規格をサポートしていない場合には可能な限り近い状態である。

5.2.1. 推奨される TLS 設定

サーバ側で適切な TLS 設定を行うことも重要である。 SSL プロトコルは非推奨であり、もはや使用するべきではない。また、 TLS v1.0 と TLS v1.1 には既知の脆弱性があり、 2020 年までにすべての主要なブラウザでその使用が非推奨となった。 TLS v1.2 および TLS v1.3 は、安全なデータ通信のためのベストプラクティスと考えられている。

クライアントとサーバの両方が同じ組織で管理され、互いに通信するためだけに使用されている場合、設定を強化することでセキュリティを強化できる。

モバイルアプリケーションが特定のサーバに接続する場合、そのネットワークスタックを調整することで、サーバの構成に対して可能な限り高いセキュリティレベルを確保することができる。オペレーティングシステムのサポートが不十分な場合、モバイルアプリケーションはより弱い構成を使用せざるを得なくなる可能性がある。

アプリの目的の一部である可能性があるため、対応する正当な理由の確認を忘れないこと。

以下へ検討する対象となる正当な理由の一例を示す。

  • アプリが、安全な接続をサポートしていない別のエンティティによって管理されているサーバに接続する必要がある。

  • アプリが、安全な接続を使用するバージョンへアップグレードできず、パブリックホスト名を使用してアクセスする必要があるデバイスへの接続をサポートする必要がある。

  • アプリが、さまざまなソースからの埋め込まれた Web コンテンツを表示する必要があるが、Web コンテンツの例外でサポートされているクラスを使用することはできない。

  • アプリが、暗号化され個人情報を含まないメディアコンテンツを読み込む。

アプリを App Store に提出する際は、App Store が既定で安全な接続を確立できない理由を判断できるように、十分な情報を提供すること。

特定のエンドポイントに通信する際に、どの ATS 設定が使用できるかを確認することができる。 macOS では、コマンドラインユーティリティの nscurl を使用することができる。指定されたエンドポイントに対して、異なる設定の並べ替えが実行され、検証される。 ATS のデフォルトのセキュアな接続テストにパスしていれば、 ATS はデフォルトのセキュアな設定で使用することができる。 nscurl の出力に失敗がある場合は、クライアント側の ATS の設定を脆弱化するのではなく、サーバ側の TLS の設定をよりセキュアになるように変更する。詳細は Apple Developer Documentation の記事「 Identifying the Source of Blocked Connections 」を参照。

詳細は、「Testing Network Communication」の章の「Verifying the TLS Settings」の項を参照する。

参考資料

ルールブック

5.2.2. 推奨される暗号スイート

暗号スイートの構造は以下の通りである。

Protocol_KeyExchangeAlgorithm_WITH_BlockCipher_IntegrityCheckAlgorithm

この構造には以下が含まれる。

  • 暗号化で使用されるプロトコル

  • TLS ハンドシェイク中にサーバとクライアントが認証に使用する鍵交換アルゴリズム

  • メッセージストリームの暗号化に使用されるブロック暗号

  • メッセージの認証に使用される完全性保証チェックアルゴリズム

例： TLS_RSA_WITH_3DES_EDE_CBC_SHA

上記の例では、以下の暗号化スイートが使用されている。

  • プロトコルとしての TLS

  • 認証のための RSA 非対称暗号化

  • EDE_CBC モードによる対称暗号化のための 3DES

  • 完全性のための SHA ハッシュアルゴリズム

TLSv1.3 では、鍵交換アルゴリズムは暗号スイートの一部ではなく、TLS ハンドシェイク中に決定されることに注意する。

次のリストでは、暗号スイートの各部分のさまざまなアルゴリズムを紹介する。

プロトコル :

鍵交換アルゴリズム :

ブロック暗号 :

完全性チェックアルゴリズム :

暗号スイートの効率は、そのアルゴリズムの効率に依存することに注意する必要がある

以下のリソースは、 TLS で使用するために推奨される最新の暗号スイートが含まれている。

iOS の一部バージョンでは、推奨する暗号スイートに対応していないものもあるため、互換性のために、 iOS のバージョンでサポートされている暗号スイートを確認し、上位の暗号スイートを選択することが可能である。

サーバが適切な暗号スイートをサポートしているかどうかを確認する場合は、さまざまなツールを使用できる。

  • nscurl - 詳細については、 iOS ネットワーク通信を参照。

  • testssl.sh は、「 TLS/SSL 暗号、プロトコル、およびいくつかの暗号の欠陥のサポートについて、任意のポートでサーバのサービスをチェックする無料のコマンドラインツール」である。

最後に、 HTTPS 接続が終了するサーバまたは終了プロキシが、ベストプラクティスに従って設定されていることを確認する。 OWASP Transport Layer Protection cheat sheet および Qualys SSL/TLS Deployment Best Practices を参照する。

参考資料

ルールブック

5.2.3. ルールブック

  1. 安全な通信プロトコル（必須）

  2. TLS で推奨される暗号化スイート（推奨）

5.2.3.1. 安全な通信プロトコル（必須）

サーバ側で適切な TLS 設定を行うことも重要である。 SSL プロトコルは非推奨であり、もはや使用するべきではない。

非推奨プロトコル

  • SSL

  • TLS v1.0

  • TLS v1.1

TLS v1.0 と TLS v1.1 については、2020 年までにすべての主要なブラウザでその使用が非推奨となった。

推奨プロトコル

  • TLS v1.2

  • TLS v1.3

これに違反する場合、以下の可能性がある。

  • セキュリティエクスプロイトに対して脆弱である。

5.2.3.2. TLS で推奨される暗号化スイート（推奨）

以下は推奨される暗号化スイートの一例。(TLS Cipher Suites で推奨されている暗号化スイートの中で、iOSで定義されているものを記載。)

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_PSK_WITH_AES_128_GCM_SHA256

  • TLS_DHE_PSK_WITH_AES_256_GCM_SHA384

  • TLS_AES_128_GCM_SHA256

  • TLS_AES_256_GCM_SHA384

  • TLS_CHACHA20_POLY1305_SHA256

  • TLS_AES_128_CCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

これに注意しない場合、以下の可能性がある。

  • 脆弱な暗号化スイートを使用する可能性がある。

5.3. MSTG-NETWORK-3

セキュアチャネルが確立されたときに、アプリはリモートエンドポイントのX.509証明書を検証している。信頼されたCAにより署名された証明書のみが受け入れられている。

※証明書検証に関する記載は「安全なネットワーク通信の設定」へ纏めて記載するため、本章での記載を省略