ATS Exemptions were identified within the app and need to be reviewed to ensure they are both appropriate and have allowable exemptions.
On Apple platforms, a networking security feature called App Transport Security (ATS) improves privacy and data integrity for all apps and app extensions. ATS blocks connections that don't meet minimum security requirements. In some cases it may be necessary to connect to a server that isn't fully secure and cannot be reconfigured. In this case, exemptions can be added to the ATS requirements. By allowing exemptions, the app may be able to communicate using insecure network protocols which can lead to data exposure or manipulation. Unless absolutely necessary, ATS exemptions should always be avoided. If absolutely required, an additional and continuous review of the data transmitted must be performed to ensure changes to the app, SDK, or the API endpoints called do not lead to security issues.
Adding certain ATS exceptions to the app's Information Property List file requires a justification to be provided and may trigger additional App Store review for the app. Using ATS can prevent man-in-the-middle attacks in situations where weak ciphers and/or old versions of TLS are used since valid self-signed certificates are accepted. This client side protection can be used to enforce widely-adopted best practice network security standards and should be used on all apps.
Steps to Reproduce
Examine the app's information properties file to evaluate the ATS exemptions.
Business Impact
Creating ATS exemptions can cause app store review processes to take longer than those using the "default" configuration. This may deny an organization the ability to distribute a critical update (security, performance, functionality, etc) as quickly as business needs dictate, therefore negatively impacting business operations.
In addition, if exemptions allow for insecure protocol usage, this allows for the use of HTTP or other weak protocols for network communications which may affect the organizations compliance requirements and confidentiality goals.
Remediation Resources
Recommended Fix
Ensure that the server meets the following minimum security requirements to avoid having to implement any ATS exemptions:
The certificate has an intact digital signature that shows the certificate has not been tampered with.
The certificate has not expired.
The certificate has a name that matches the server's DNS name.
The certificate is signed by another valid certificate, which is in turned signed by another, and so on back to a trusted anchor certificate. The trusted anchor certificate must be issued by a Certificate Authority (CA). The anchor certificate must be part of the client operating system, as indicated in lists of available trusted root certificates in iOS, or be installed on the client by the user or a system administrator.
The server certificate must be signed with either a Rivest-Shamir-Adleman (RSA) key of at least 2048 bits or an Elliptic-Curve Cryptography (ECC) key of at least 256 bits.
The certificate must use the Secure Hash Algorithm 2 (SHA-2) with a digest length, sometimes called a fingerprint, of at least 256 bits (SHA-256 or greater).
The connection must use Transport Layer Security (TLS) protocol version 1.2 or later.
Data must be exchanged using either the AES-128 or the AES-256 symmetric cipher.
The link must support perfect forward secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.
If the server cannot be configured according to the minimum security requirements mentioned above, ensure that the justifications associated with each of the listed exemptions provides sufficient information for the App Store to determine why the app cannot make secure connections by default. Failure to do so may result in rejection from the App Store. Examples of justifications include:
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.
Code Samples
Bad Code Sample (.plist)
// Inside the app's information properties file,
// You can configure ATS exceptions with this dictionary,
// where all keys are optional
NsAppTransportSecurity : Dictionary {
NSAllowsArbitraryLoads : YES
NSAllowsArbitraryLoadsForMedia : YES
NSAllowsArbitraryLoadsInWebContent : YES
NSAllowsLocalNetworking : YES
NsExceptionDomains : Dictionary {
<domain-name-string> : Dictionary {
NSIncludesSubdomains : YES
NSExceptionAllowsInsecureHTTPLoads : YES
NSExceptionMinimumTLSVersion : <string>
NSExceptionRequiresForwardSecrecy : YES
NSRequiresCertificateTransparency : YES
}
}
}
// Setting any of the arbitrary load bools to YES completely disables ATS for the respective component.
Good Code Sample 2 (.plist)
// Exceptions should only be configured when absolutely needed
// You should first try to fix the security of the server
NsAppTransportSecurity : Dictionary {
NSAllowsArbitraryLoads : NO // ATS enabled
}
Finding Description
ATS Exemptions were identified within the app and need to be reviewed to ensure they are both appropriate and have allowable exemptions.
On Apple platforms, a networking security feature called App Transport Security (ATS) improves privacy and data integrity for all apps and app extensions. ATS blocks connections that don't meet minimum security requirements. In some cases it may be necessary to connect to a server that isn't fully secure and cannot be reconfigured. In this case, exemptions can be added to the ATS requirements. By allowing exemptions, the app may be able to communicate using insecure network protocols which can lead to data exposure or manipulation. Unless absolutely necessary, ATS exemptions should always be avoided. If absolutely required, an additional and continuous review of the data transmitted must be performed to ensure changes to the app, SDK, or the API endpoints called do not lead to security issues.
Adding certain ATS exceptions to the app's Information Property List file requires a justification to be provided and may trigger additional App Store review for the app. Using ATS can prevent man-in-the-middle attacks in situations where weak ciphers and/or old versions of TLS are used since valid self-signed certificates are accepted. This client side protection can be used to enforce widely-adopted best practice network security standards and should be used on all apps.
Steps to Reproduce
Examine the app's information properties file to evaluate the ATS exemptions.
Business Impact
Creating ATS exemptions can cause app store review processes to take longer than those using the "default" configuration. This may deny an organization the ability to distribute a critical update (security, performance, functionality, etc) as quickly as business needs dictate, therefore negatively impacting business operations.
In addition, if exemptions allow for insecure protocol usage, this allows for the use of HTTP or other weak protocols for network communications which may affect the organizations compliance requirements and confidentiality goals.
Remediation Resources
Recommended Fix
Ensure that the server meets the following minimum security requirements to avoid having to implement any ATS exemptions:
If the server cannot be configured according to the minimum security requirements mentioned above, ensure that the justifications associated with each of the listed exemptions provides sufficient information for the App Store to determine why the app cannot make secure connections by default. Failure to do so may result in rejection from the App Store. Examples of justifications include:
Code Samples
Bad Code Sample (.plist)
Good Code Sample 2 (.plist)
Additional Guidance
Risk and Regulatory Information
Severity: medium CVSS: 5.3
Application
See more detail in the NowSecure Report