ATS Auditing
The .ipa is now unzipped and the Info.plist file is converted into a readable format and opened. Now, locate the “App Transport Security Settings,” and there you will find the current ATS configuration which will look something like this:
There you’ll see the app’s ATS primary and subkeys. Each key helps developers configure the app’s ATS implementation and make exceptions for domains that can’t support ATS.
NSAppTransportSecurity configuration keys, subkeys, and exceptions
To help security analysts understand the various ATS exceptions and how they affect the security posture of an iOS app, I’ve described them below.
NSAllowArbitraryLoads
The NSAllowArbitraryLoads key is set to NO by default. Setting the key to YES will opt-out of ATS and its associated security benefits. If in testing an app you find this key set to YES, verify why the developers decided to opt out. In addition, check into the NSExceptionDomains exception and whether any domains are listed there. We’ve encountered a number of cases where developers have opted out of ATS globally, but then opted in only for certain domains by listing an exception domain. A better approach is to enable ATS globally, and only opt out for certain domains if absolutely necessary (more on that in the NSExceptionDomains section below).
If they key is set to YES, spend time verifying:
The ciphers used for the app’s backend connections (and that they’re strong)
The protocols used to send and retrieve data (and that they’re secure)
Whether the app has any downgrade vulnerabilities
Whether the app validates certificates used for TLS connections
While you should perform testing in these areas regardless of the ATS configuration, a developer setting this key to YES increases risks in these areas.
NSAllowsLoadsForMedia
This exception is for media content protected by digital rights management (DRM) or encryption. When the NSAllowsLoadsForMedia key is set to YES, ATS is disabled for content sent using the AVFoundation framework (typically the case with apps that include audiovisual recording, editing, or playback functionality). If making sure your app’s media content is sent securely over the network is important to you and this key is enabled, confirm that media sent by the app is free of sensitive content and protected using DRM or encryption. While it’s best practice to implement these protections even if content is transmitted over HTTPS, capturing the transmitted content over HTTP or other insecure protocols is trivial.
NSAllowsArbitraryLoadsInWebContent
By default, NSAllowsArbitraryLoadsInWebContent is set to NO. When the key is set to YES, ATS is disabled for webview requests. You would usually see this exception if a webview is used within the app. In that case, you’ll want to assess whether the webview sends sensitive data. That’s because with the key enabled, data can be sent over HTTP or other insecure protocols or connections.
Using webviews can introduce vulnerabilities into an app, so it’s crucial to verify their security. For example, webviews can be vulnerable to a number of common web-based vulnerabilities such as SQL injection, cross-site request forgery, and cross-site scripting attacks. For additional security information about using webviews, check out our webviews best practices.
NSAllowsLocalNetworking
NSAllowsLocalNetworking is set to NO by default. Setting it to YES will disable ATS for connections over a local network. Typical use cases for this exception might be apps that connect to a local hardware device in an Internet-of-Things (IoT) scenario. Apps that facilitate local peer-to-peer connections may also use this exception. If you run into this exception when testing an app, replicate the environment within which this local connection would take place to check for sensitive data sent over the local network in an insecure method. Even if an app connects to a local device, a best security practice is to use a TLS connection between those endpoints.
NSExceptionDomains and subkeys
NSExceptionDomains
Using the NSExceptionDomains key, developers can configure ATS exceptions on a domain-by-domain basis. Security analysts should note that ATS subkeys within NSExceptionDomains supersede other primary keys. For example, if an app loads media from a specific domain and both the NSAllowsLoadsForMedia exception and a NSExceptionDomains configuration is used for that particular domain, the NSExceptionDomains subkey parameters supersede the NSAllowsLoadsForMedia key parameters.
Security analysts should also note that without additional configuration using the subkeys underneath the primary NSExceptionDomain key, connections between the app and a listed domain will enforce ATS on the connection (even with NSAllowsArbitraryLoads set to YES). Put another way — if an exception domain is listed without any configuration of the subkeys, that domain will receive full ATS protection, even if the NSAllowsArbitraryLoads is set to YES. This can complicate analysis because a developer can shut off ATS globally but turn it on for specific domains by listing them within the NSExceptionDomains key.
Some developers are tempted to opt-out globally and opt-in for specific domains. However, a better practice is to leave ATS globally enabled for better protection coverage and only exempt domains your organization doesn’t control (the intended use case for the NSExceptionDomain key). And even then, only if necessary. Explain to your development team that coding logical ATS subkey exceptions will simplify the justification used for each exception and make life easier in the long run when Apple enforces a deadline. ATS should be enabled globally, and exceptions to ATS created through the NSExceptionDomains subkeys.
If an app you’re testing uses NSExceptionDomains and sets NSAllowsArbitraryLoads to YES, make sure you’re auditing the connections between the app and back-end services. Ideally, the app is only connecting to domains listed in the top-level NSExceptionDomains key, without any further configuration in the subkeys (again, effectively opting-into ATS for specific domains). If there are connections to other domains not in that list, ATS will not be enforced for those domains.
NSIncludesSubdomains
By default this key is set to NO. When it’s set to YES, any ATS configuration enabled for a particular domain will carry through for all subdomains of the exception domain. And, if you set an exception domain, but don’t configure any additional subkeys beyond the NSIncludesSubdomains key, the exception domain and its subdomains will use ATS. If you’re testing an app that has this key enabled, approach any subdomains in the same way you would the main domain. In addition, if ATS is globally disabled, and this key is set to NO, confirm that the subdomains are not in use in the app.
NSExceptionAllowsInsecureHTTPLoads
By default this key is set to NO. When this key is set to YES, the app will be allowed to send HTTP traffic to that domain. If you see this key set to YES, make sure to take a look at what information is being sent over the network. It may be sent insecurely over HTTP. If information must be sent over HTTP, at least make sure the information sent isn’t sensitive and that all connections are secure.
NSExceptionMinimumTLSVersion
This key allows developers to lower the minimum accepted version of TLS. By default, TLS 1.2 and higher are the accepted versions. If you see this exception in place, you will want to verify the TLS configuration of that endpoint, the reason why it needed to be lowered, and that it doesn’t violate your own organization’s compliance requirements.
NSExceptionRequiresForwardSecrecy
By default this key is set to YES. If this key is set to NO it will disable perfect forward secrecy. Similar to theNSExceptionMinimumTLSVersion key, if you encounter this key in an app you’re testing, verify the TLS configuration of the endpoint, the reason why it needs to be lowered, and your own organization’s compliance requirements.
NSRequiresCertificateTransparency
By default this key is set to NO. If the key is set to YES, it will require a Certificate Transparency timestamp on the domain’s certificate. Certificate Transparency is a Google project aimed at making the SSL certificate system more secure. If your organization or the domain in question supports Certificate Transparency, you’ll want to enable this. Certificate Transparency helps audit against rogue Certificate Authorities (CAs) and malicious certificates, and it can help prevent man-in-the-middle attacks by notifying DevOps teams if their certificate has been compromised. When this key is enabled, the certificate checks associated with Certificate Transparency will be performed before a connection is made.
Last updated