5. Network Communication Requirements
5.1. MSTG-NETWORK-1
Data is encrypted on the network using TLS. The secure channel is used consistently throughout the app.
5.1.1. Configuring secure network communication
All the presented cases must be carefully analyzed as a whole. For example, even if the app does not permit cleartext traffic in its Info.plist, it might actually still be sending HTTP traffic. That could be the case if it’s using a low-level API (for which ATS is ignored) or a badly configured cross-platform framework.
IMPORTANT: You should apply these tests to the app main code but also to any app extensions, frameworks or Watch apps embedded within the app as well.
For more information refer to the article “Preventing Insecure Network Connections” and “Fine-tune your App Transport Security settings” in the Apple Developer Documentation.
Reference
Rulebook
5.1.2. Static Analysis
5.1.2.1. Verification of network requests with secure protocols
First, you should identify all network requests in the source code and ensure that no plain HTTP URLs are used. Make sure that sensitive information is sent over secure channels by using URLSession (which uses the standard URL Loading System from iOS) or Network (for socket-level communication using TLS and access to TCP and UDP).
Reference
Rulebook
5.1.2.2. Check for Low-Level Networking API Usage
Identify the network APIs used by the app and see if it uses any low-level networking APIs.
Apple Recommendation: Prefer High-Level Frameworks in Your App: “ATS doesn’t apply to calls your app makes to lower-level networking interfaces like the Network framework or CFNetwork. In these cases, you take responsibility for ensuring the security of the connection. You can construct a secure connection this way, but mistakes are both easy to make and costly. It’s typically safest to rely on the URL Loading System instead” (see source).
If the app uses any low-level APIs such as Network or CFNetwork, you should carefully investigate if they are being used securely. For apps using cross-platform frameworks (e.g. Flutter, Xamarin, …) and third party frameworks (e.g. Alamofire) you should analyze if they’re being configured and used securely according to their best practices.
Make sure that the app:
verifies the challenge type and the host name and credentials when performing server trust evaluation.
doesn’t ignore TLS errors.
doesn’t use any insecure TLS configurations (see ”Testing the TLS Settings (MSTG-NETWORK-2)”)
These checks are orientative, we cannot name specific APIs since every app might use a different framework. Please use this information as a reference when inspecting the code.
Reference
Rulebook
5.1.2.3. Testing for Cleartext Traffic
Ensure that the app is not allowing cleartext HTTP traffic. Since iOS 9.0 cleartext HTTP traffic is blocked by default (due to App Transport Security (ATS)) but there are multiple ways in which an application can still send it:
Configuring ATS to enable cleartext traffic by setting the NSAllowsArbitraryLoads attribute to true (or YES) on NSAppTransportSecurity in the app’s Info.plist.
Check that NSAllowsArbitraryLoads is not set to true globally of for any domain.
If the application opens third party web sites in WebViews, then from iOS 10 onwards NSAllowsArbitraryLoadsInWebContent can be used to disable ATS restrictions for the content loaded in web views.
Apple warns: Disabling ATS means that unsecured HTTP connections are allowed. HTTPS connections are also allowed, and are still subject to default server trust evaluation. However, extended security checks—like requiring a minimum Transport Layer Security (TLS) protocol version—are disabled. Without ATS, you’re also free to loosen the default server trust requirements, as described in “Performing Manual Server Trust Authentication”.
The following snippet shows a vulnerable example of an app disabling ATS restrictions globally.
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
ATS should be examined taking the application’s context into consideration. The application may have to define ATS exceptions to fulfill its intended purpose. For example, the Firefox iOS application has ATS disabled globally. This exception is acceptable because otherwise the application would not be able to connect to any HTTP website that does not have all the ATS requirements. In some cases, apps might disable ATS globally but enable it for certain domains to e.g. securely load metadata or still allow secure login.
ATS should include a justification string for this (e.g. “The app must connect to a server managed by another entity that doesn’t support secure connections.”).
Reference
Rulebook
5.1.3. Dynamic Analysis
Intercept the tested app’s incoming and outgoing network traffic and make sure that this traffic is encrypted. You can intercept network traffic in any of the following ways:
Capture all HTTP(S) and Websocket traffic with an interception proxy like OWASP ZAP or Burp Suite and make sure all requests are made via HTTPS instead of HTTP.
Interception proxies like Burp and OWASP ZAP will show HTTP(S) traffic only. You can, however, use a Burp plugin such as Burp-non-HTTP-Extension or the tool mitm-relay to decode and visualize communication via XMPP and other protocols.
Some applications may not work with proxies like Burp and OWASP ZAP because of Certificate Pinning. In such a scenario, please check “Testing Custom Certificate Stores and Certificate Pinning”.
For more details refer to:
“Intercepting Traffic on the Network Layer” from chapter “Testing Network Communication”
“Setting up a Network Testing Environment” from chapter iOS Basic Security Testing
Reference
Rulebook
5.1.4. Rulebook
5.1.4.1. Use App Transport Security (ATS) (Required)
The ATS requires the use of HTTPS for all HTTP connections. In addition, it imposes extended security checks that complement the default server trust rating specified by the Transport Layer Security ( TLS ) protocol; ATS blocks connections that do not meet minimum security specifications.
In order to ensure that the data used within an application is as secure as possible, it is important to first understand if the connection is currently unsecured.
To check, set the Allow Arbitrary Loads attribute to “NO” in the App Transport Security Settings of the Info.plist to disable all active ATS exceptions. If an application makes an unsecured connection, a runtime error will occur on Xcode for each connection.
ATS is effective when:
App Transport Security Settings is not specified in Info.plist.
In Info.plist, “NO” is specified for “Allow Arbitrary Loads” attribute, “Allows Arbitrary Loads for Media” attribute, “Allows Arbitrary Loads in Web Content” attribute, and “NSExceptionAllowsInsecureHTTPLoads” attribute, and “NSExceptionRequiresForwardSecrecy” attribute is “YES” is specified and 1.2 or higher is specified in the “NSExceptionMinimumTLSVersion” attribute.
info.plist setting on Xcode:
Fig 5.1.4.1.1 Example of exclusion by ATS
If this is violated, the following may occur.
May implement connections that do not meet security specifications.
5.1.4.2. Using URLSession (Recommended)
To manipulate URLs and communicate with servers using standard Internet protocols, iOS provides a URL Loading System. URLSession is used for this purpose.
import UIKit
class Fetch {
func getDataAPI(completion: @escaping (Any) -> Void) {
let requestUrl = URL(string: "http://xxxxx")!
// Use URLSession's datatask to acquire data.
let task = URLSession.shared.dataTask(with: requestUrl) { data, response, error in
// Process when an error is returned.
if let error = error {
completion(error)
} else if let data = data {
completion(data)
}
}
task.resume()
}
}
If this is not noted, the following may occur.
Sensitive information may be transmitted over insecure channels.
5.1.4.3. Use CFNetwork (Deprecated)
CFNetwork is an API for BSD socket handling, HTTP and FTP server communication provided in iOS 2.0.
Most of them are now deprecated. URLSession (using the standard iOS URL Loading System) is recommended for ATS to function effectively.
The reasons for this deprecation are as follows.
Sensitive information may be transmitted over insecure channels.
5.1.4.4. Using the Network Framework (Recommended)
Use when direct access to TLS, TCP, UDP or proprietary application protocols is required. Use URLSession as before for HTTP(S) and URL-based resource loading.
import Foundation
import Network
class NetworkUDP {
// Constant
let networkType = "_myApp._udp."
let networkDomain = "local"
private func startListener(name: String) {
// Create listener with udp for using
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")
// Processing new connection visits
listener.newConnectionHandler = { [unowned self] (connection: NWConnection) in
connection.start(queue: listnerQueue)
self.receive(on: connection)
}
// Listener start
listener.start(queue: listnerQueue)
}
private func receive(on connection: NWConnection) {
/* Data reception */
connection.receive(minimumIncompleteLength: 0,
maximumLength: 65535,
completion:{(data, context, flag, error) in
if let error = error {
NSLog("\(#function), \(error)")
} else {
if data != nil {
/* Deserialization of incoming data */
}
else {
NSLog("receiveMessage data nil")
}
}
})
}
}
If this is not noted, the following may occur.
Sensitive information may be transmitted over insecure channels.
5.1.4.5. Use low-level networking APIs safely according to best practices (Required)
If your app uses low-level APIs, you need to carefully investigate whether they are being used safely. If the app uses cross-platform frameworks (e.g. Flutter, Xamarin) or third-party frameworks (e.g. Alamofire), it should be analyzed to ensure that they are being configured and used safely according to best practices.
Ensure that the app complies with the following: * Verify that the app is compliant with the
Validate challenge type and hostname and credentials when performing server reliability assessments.
Do not ignore TLS errors.
Not using insecure TLS settings. （”See Verify TLS settings (MSTG-NETWORK-2)”）
These checks are for reference only and cannot name specific APIs, as each application may use a different framework. They should be used as reference information when examining the code.
If this is violated, the following may occur.
The app may conduct insecure communication.
5.2. MSTG-NETWORK-2
The TLS settings are in line with current best practices, or as close as possible if the mobile operating system does not support the recommended standards.
5.2.1. Recommended TLS Settings
Ensuring proper TLS configuration on the server side is also important. The SSL protocol is deprecated and should no longer be used. Also TLS v1.0 and TLS v1.1 have known vulnerabilities and their usage is deprecated in all major browsers by 2020. TLS v1.2 and TLS v1.3 are considered best practice for secure transmission of data.
When both the client and server are controlled by the same organization and used only for communicating with one another, you can increase security by hardening the configuration.
If a mobile application connects to a specific server, its networking stack can be tuned to ensure the highest possible security level for the server’s configuration. Lack of support in the underlying operating system may force the mobile application to use a weaker configuration.
Remember to inspect the corresponding justifications to discard that it might be part of the app intended purpose.
Some examples of justifications eligible for consideration are:
The app must connect to a server managed by another entity that doesn’t support secure connections.
The app must support connecting to devices that cannot be upgraded to use secure connections, and that must be accessed using public host names.
The app must display embedded web content from a variety of sources, but can’t use a class supported by the web content exception.
The app loads media content that is encrypted and that contains no personalized information.
When submitting your app to the App Store, provide sufficient information for the App Store to determine why your app cannot make secure connections by default.
It is possible to verify which ATS settings can be used when communicating to a certain endpoint. On macOS the command line utility nscurl can be used. A permutation of different settings will be executed and verified against the specified endpoint. If the default ATS secure connection test is passing, ATS can be used in its default secure configuration. If there are any fails in the nscurl output, please change the server side configuration of TLS to make the server side more secure, rather than weakening the configuration in ATS on the client. See the article “Identifying the Source of Blocked Connections” in the Apple Developer Documentation for more details.
Refer to section “Verifying the TLS Settings” in chapter Testing Network Communication for details.
Reference
Rulebook
5.2.2. Recommended Cipher Suites
Cipher suites have the following structure:
Protocol_KeyExchangeAlgorithm_WITH_BlockCipher_IntegrityCheckAlgorithm
This structure includes:
A Protocol used by the cipher
A Key Exchange Algorithm used by the server and the client to authenticate during the TLS handshake
A Block Cipher used to encrypt the message stream
A Integrity Check Algorithm used to authenticate messages
Example: TLS_RSA_WITH_3DES_EDE_CBC_SHA
In the example above the cipher suites uses:
TLS as protocol
RSA Asymmetric encryption for Authentication
3DES for Symmetric encryption with EDE_CBC mode
SHA Hash algorithm for integrity
Note that in TLSv1.3 the Key Exchange Algorithm is not part of the cipher suite, instead it is determined during the TLS handshake.
In the following listing, we’ll present the different algorithms of each part of the cipher suite.
Protocols:
SSLv1
SSLv2 - RFC 6176
SSLv3 - RFC 6101
TLSv1.0 - RFC 2246
TLSv1.1 - RFC 4346
TLSv1.2 - RFC 5246
TLSv1.3 - RFC 8446
Key Exchange Algorithms:
DSA - RFC 6979
ECDSA - RFC 6979
RSA - RFC 8017
ECDHE - RFC 4492
PSK - RFC 4279
DSS - FIPS186-4
ECDHE_ECDSA - RFC 8422
ECDHE_RSA - RFC 8422
Block Ciphers:
DES - RFC 4772
DES_CBC - RFC 1829
3DES - RFC 2420
3DES_EDE_CBC - RFC 2420
AES_128_CBC - RFC 3268
AES_128_GCM - RFC 5288
AES_256_CBC - RFC 3268
AES_256_GCM - RFC 5288
RC4_40 - RFC 7465
RC4_128 - RFC 7465
Integrity Check Algorithms:
Note that the efficiency of a cipher suite depends on the efficiency of its algorithms.
The following resources contain the latest recommended cipher suites to use with TLS:
IANA recommended cipher suites can be found in TLS Cipher Suites.
OWASP recommended cipher suites can be found in the TLS Cipher String Cheat Sheet.
Some iOS versions do not support some of the recommended cipher suites, so for compatibility purposes you can check the supported cipher suites for iOS versions and choose the top supported cipher suites.
If you want to verify whether your server supports the right cipher suites, there are various tools you can use:
nscurl - see iOS Network Communication for more details.
testssl.sh which “is a free command line tool which checks a server’s service on any port for the support of TLS/SSL ciphers, protocols as well as some cryptographic flaws”.
Finally, verify that the server or termination proxy at which the HTTPS connection terminates is configured according to best practices. See also the OWASP Transport Layer Protection cheat sheet and the Qualys SSL/TLS Deployment Best Practices.
Reference
Rulebook
5.2.3. Rulebook
5.2.3.1. Secure communication protocol (Required)
Ensuring proper TLS configuration on the server side is also important. The SSL protocol is deprecated and should no longer be used.
Deprecated Protocols
SSL
TLS v1.0
TLS v1.1
TLS v1.0 and TLS v1.1 have been deprecated in all major browsers by 2020.
Recommended Protocols
TLS v1.2
TLS v1.3
If this is violated, the following may occur.
Vulnerable to security exploits.
5.2.3.2. Recommended cipher suites for TLS (Recommended)
The following is an example of a recommended cipher suite. (Lists the cipher suites defined by iOS among those recommended by TLS Cipher Suites.)
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
If this is not noted, the following may occur.
Potential use of vulnerable cipher suites.
5.3. MSTG-NETWORK-3
The app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted.
* The description of certificate validation is summarized in “Configuring secure network communication” and is omitted from this chapter.