Digging into AppBoundDomains in iOS
iOS 14 issued a number of changes, as every new release does. But one area where Apple clearly spent a fair amount of time is in their WebViews. Traditionally, UIWebView was the class de jour when a developer wanted to present a web page. In iOS 14 though, UIWebView was officially deprecated in favor of WKWebView.
Browser integration has always been a core security concern with iOS, as MobileSafari is the only application that allows the dynamic-code-signing element, to sign generated code, in particular: Javascript. Unfortunately, Javascript exploits have continued to proliferate throughout the world, and iOS is no exception, see this article and this support page for some recent (and highly prominent) examples. These exploits have grown increasingly sophisticated as compared to some of the early examples—check out this page for an albeit old but strikingly simple denial-of-service exploit, i.e. crashing the user’s phone.
Apple introduced the concept of AppBoundDomains to limit exposure to third-party Javascript, something app developers are, and should, be taking advantage of. The concept is relatively straightforward. By creating an entry in the application’s Info.plist the developers list those sites that they trust the incoming Javascript so far as to allow that website access to the WKWebView methods:
(void)evaluateJavaScript:(NSString *)javaScriptString completionHandler:(void (^ _Nullable)(_Nullable id, NSError * _Nullable error))completionHandler
(void)addUserScript:(WKUserScript *)userScript;
window.webkit.messageHandlers
Cookie handling is all possible to control as well. Access to the following methods, as described in this blog, is also controlled via the same process.
(void)setCookie:(NSHTTPCookie *)cookie completionHandler:(nullable void (^)(void))completionHandler;
(void)getAllCookies:(void (^)(NSArray
The WebKit blog article gives several use cases, and Apple also provided some guidance in a WWDC 2020 video (watch here), where they explicitly said that using AppBoundDomains is a best practice.
Veracode has kept up by being able to scan instances of WKWebView in an application’s code and ensure that a proper AppBoundDomain entry has been tied to that in the application bundle. If not, we’ll alert our customers to that effect, and in those cases usually, a quick fix is all that’s necessary, as Apple made this easy to integrate into the application.
This is one of the more important, even if straightforward, developments in iOS 14, as anyone who has followed JavaScriptCore and other underlying libraries can tell. It’s not a coincidence that many security conferences perennially have very interesting demonstrations and content based on Javascript exploits. Dynamic code has been and likely always will be a security risk to incorporate and so Apple has provided a strong means to limit exposure.
Most of these efforts have been made to ensure that built-in privacy protections became the norm on iOS. In the older UIWebView, private data can and has been taken, and this protection is a means to prevent that. For Desktop Safari users, you might notice that recent versions of OS X will now prevent some website trackers from tracking your browsing history, and other data. We live in a connected world, busily browsing the internet, but without the right protections the services provided tend to take the same attitude towards you, and that certainly includes your data.
To learn more about iOS security, visit our knowledge base.
*** This is a Security Bloggers Network syndicated blog from Application Security Research, News, and Education Blog authored by Thu, 03 Jun 2021 10:32:33 -0400. Read the original post at: https://www.veracode.com/blog/managing-appsec/appbounddomains-ios
