Archiv der Kategorie: #iOSProTip

If your iOS code signing fails today

If your iOS code signing fails today, it may be due to an expired Apple Intermediate Certificate.

What you need for code signing beside your valid developer or distribution certificate is the
Apple Worldwide Developer Relations Certification Authority. It expired yesterday and there’s probably already a new one side by side in your keychain. (If not, download and install the new one here: WWDR Certificate (Expiring 02/07/23)) Alas, the expired one interferes with the chain of trust and as a result you get a

„This certificate has an invalid issuer.“

To get rid of this error, you simply have to delete the expired one
in three easy steps:

  1. Open the Keychain Access utility
  2. In the menu, select View -> Show Expired Certificates
    Screen Shot 2016-02-15 at 10.50.14
  3. Make sure to delete the expired “Apple Worldwide Developer Relations*” certificates from all keychains (probably login and system).
    Screen Shot 2016-02-15 at 10.50.06 copy

Now everything should work like a charm again 😉

UIWebView Cross Site Scripting Vulnerability

When integrating UIWebViews you have to pay attention to how the desired webpage is being loaded.
That’s why Apple lately added the following lines to the documentation of UIWebView:

To help you avoid being vulnerable to security attacks, be sure to use this method [-loadHTMLString:baseURL:] to load local HTML files; don’t use loadRequest:.

Loading a website via loadRequest: bears the risk of Cross Site Scripting, since it does not enforce the Same Origin Policy, i.e., access to resources of other websites or within the bundle container of the app is possible.

When installing an app on iOS, the following containers are being generated:

  • Bundle container
  • Data container
  • possibly an iCloud container

Without enforcing the Same Origin Policy a HTML file running inside a UIWebView can access resources within the bundle container of the app.

Example Attack Scenario

Screen Shot 2015-08-04 at 13.22.40
Hacking an app’s imprint webview with the aid of Charles.

Applying a Man-in-the-middle attack I could pass a primed website off as the desired app’s imprint website. An attacker could now prompt for sensitive data and capture it.

Furthermore, the attacker could access sqlite cache files or other sensitive resources inside the bundle container. But since this attack requires guessing the id of the sandbox, which is part of the required URL, this is not very likely to happen.

Solution

A solution is to use the methodsloadData:baseURL:orloadData:MIMEType:textEncodingName:baseURL: to load external websites and specifying the baseURL property to point to the host of the desired website, preventing access to resources on different hosts.

Alternatively you could implement webView:shouldStartLoadWithRequest:navigationType: of the UIWebViewDelegate protocol, inspecting every request’s host address and whitelisting which to allow.

Key-Value Observing Affected Keys

I like to write handy names for my properties like so:

@property (nonatomic, assign, getter = isLoading) BOOL loading;

As you can see I’ve defined a special name for the getter: isLoading.

There’s only one problem with this:

If another class is observing this class key path loading, it won’t get notified about changes, unless you overwrite your setter like so:

- (void)setLoading:(BOOL)loading
{
    [self willChangeValueForKey:NSStringFromSelector(@selector(isLoading))];
    _loading = loading;
    [self didChangeValueForKey:NSStringFromSelector(@selector(isLoading))];
}

Yesterday I stumbled upon a new way to solve this and a very related problem if different keys are affecting each other.

Registering Dependent Keys

You can implement a class method that follows the naming convention keyPathsForValuesAffecting<Key> to trigger notifications automatically for a (to-one relationship to a) dependent keyPath.

The above snippet could be abandoned using the following implementation:

+ (NSSet *)keyPathsForValuesAffectingIsLoading 
{
    return [NSSet setWithObjects:NSStringFromSelector(@selector(isLoading)), nil];
}

As you can see, the above method returns an instance of NSSet, allowing to specify a bunch of dependent properties that might change dependently.

Here’s the link to the Apple documentation on this topic: Key-Value Observing Programming Guide