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:
Open the Keychain Access utility
In the menu, select View -> Show Expired Certificates
Make sure to delete the expired “Apple Worldwide Developer Relations*” certificates from all keychains (probably login and system).
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:
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
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.
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.