# ATS Auditing {% hint style="info" %} **Content taken from** [**https://www.nowsecure.com/blog/2017/08/31/security-analysts-guide-nsapptransportsecurity-nsallowsarbitraryloads-app-transport-security-ats-exceptions/**](https://www.nowsecure.com/blog/2017/08/31/security-analysts-guide-nsapptransportsecurity-nsallowsarbitraryloads-app-transport-security-ats-exceptions/) {% endhint %} 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: ``` NSAppTransportSecurity : Dictionary { NSAllowsArbitraryLoads : Boolean NSAllowsArbitraryLoadsForMedia : Boolean NSAllowsArbitraryLoadsInWebContent : Boolean NSAllowsLocalNetworking : Boolean NSExceptionDomains : Dictionary { : Dictionary { NSIncludesSubdomains : Boolean NSExceptionAllowsInsecureHTTPLoads : Boolean NSExceptionMinimumTLSVersion : String NSExceptionRequiresForwardSecrecy : Boolean NSRequiresCertificateTransparency : Boolean } } } ``` 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](https://developer.apple.com/documentation/avfoundation) (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](https://books.nowsecure.com/secure-mobile-development/en/webviews/). #### 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 the`NSExceptionMinimumTLSVersion` 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](https://www.certificate-transparency.org/) 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://wiki.smhuda.com/pentesting/application-security/mobile-security/ios/ats-auditing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.