iOS ATS - 它是如何工作的，以及这么多应用程序如何忽略它

Question

这是一个关于应用程序传输安全的更一般的问题/讨论。 ATS 确保 iPhone 和互联网之间的所有网络流量都安全完成（即 HTTPS）。这在理论上确实很好，除了很多网站没有 HTTPS 版本。我对这个主题所做的大部分阅读归结为：

“好的，这不是问题，因为我们的应用只需要与我们的后端对话，我们可以控制安全性”

但是，如果您的应用不与一个后端通信怎么办？如果您没有那么多控制权怎么办？

“我的应用从各种来源进行新闻聚合，这些来源可能有也可能没有 HTTPS 链接，我无法控制它们是否有”

例如，ESPN 的面向公众的网站没有 HTTPS 端点。如果您转到https://espn.com，它会将您重定向到http://espn.com

对此问题的另一个常见响应是：“好的，将 espn 添加到您的ATS Exception Domains”

更笼统 - 像 Facebook 这样使用自己的内置浏览器的应用程序如何处理人们在其时间线中发布链接可能使用也可能不使用 HTTPS 链接的事实？他们肯定不会在info.plist 中将整个互联网列入白名单

有什么想法吗？我知道这是一个相当广泛且开放式的问题，但我真的想弄清楚什么是遵守 ATS 并允许在应用中获得良好冲浪体验的最佳方式。

Answer 1

基本上，您应该根据应用的需要启用尽可能少的异常来处理此问题。 SO上的许多答案都指导开发人员一起禁用ATS。这很糟糕有两个原因 -

1. 它可能会降低您的应用通信的安全性
2. 在某些时候，Apple 将开始强制执行他们的理由 在 2016 年 WWDC 上向开发者介绍。

不过，您走在正确的轨道上。如果应用程序正在从不支持 HTTPS（或前向保密或 TLS 1.2）的服务器访问服务器基础资源，则应仅针对 ATS 缺乏的区域添加 NSExceptionUrls。同样，如果 URL 支持 TLS 1.2，但不支持前向保密，请不要禁用所有 ATS。在这种情况下，只需添加要求前向保密的例外。这将使未来与 Apple 的辩护变得更加容易——“我们不控制服务器，或者我们可以支持前向保密，但我们仍然允许 ATS 保护应用程序用户的其他一切。

对于未知服务器，例如用户指定的服务器，您可能必须全局禁用 ATS，并出现 NSAllowsArbitraryLoads 异常。但是，不要止步于此。如果您确实连接到自己的符合 ATS 的服务器，则可以添加一个 URL 例外，以便为该 URL 启用 ATS。同样，这向 Apple 表明您正在尽可能地实施 aTS 保护。

最后，对于特定的内容（比如网页浏览），你不一定能控制你的用户去哪里，所以你可以指定NSAllowsArbitraryLoadsInWebContent 异常来保护不在 WKWebView 或 SFSafariViewController 中的所有内容，同时让用户浏览可能不支持所有 ATS 要求的网站。

所以，长话短说，尽量让 ATS 保持开启状态，这样您就可以最好地保护用户的隐私/数据，同时仍然为他们提供所需的功能。当 Apple 开始要求您为 ATS 例外提供理由时，采取这种努力肯定会有所帮助。