Tags:
This is a guest post from security researcher Nitesh Dhanjani. Nitesh will be giving a talk on "Hacking and Securing Next Generation iPhone and iPad Apps" at SANS AppSec 2011
In this article, I will discuss the security concerns I have regarding how URL Schemes are registered and invoked in iOS.
URL Schemes, as Apple refers to them, are URL Protocol Handlers that can be invoked by the Safari browser. They can also be used by applications to launch other applications to perform certain transactions, but this use case isn?t relevant to the scope of this discussion.
In the URL Scheme Reference document, Apple lists the default URL Schemes that are registered within iOS. For example, the tel: scheme can be used to launch the Phone application. Now, imagine if a website were to contain the following HTML rendered to someone browsing using Safari on iOS:
<iframe src="tel:1-408-555-5555"></iframe>
In this situation, Safari displays an authorization dialog:
Fantastic. A malicious website should not be able to initiate a phone call without the user?s explicit permission. This is the right behavior from a security perspective.
Now, let us assume the user has Skype.app installed. Let us also assume that the user has launched Skype in the past and that application has cached the user?s credentials (this is most often the case: users on mobile devices don?t want to repeatedly enter their credentials so this is not an unfair assumption). Now, what do you think happens when a malicious site renders the following HTML?
<iframe src="skype://14085555555?call"></iframe>
In this case, Safari throws no warning, and yanks the user into Skype which immediately initiates the call. The security implications of this is obvious, including the additional abuse case where a malicious site can make Skype.app call a Skype-id who can then uncloak the victim?s identity (by analyzing the victim?s Skype-id from the incoming call).
I contacted Apple?s security team to discuss this behavior, and their stance is that the onus is on the third-party applications (such as Skype in this case) to ask the user for authorization before performing the transaction. I also contacted Skype about this issue, but I have not heard back from them.
I do agree with Apple that third-party applications should also take part in ensuring authorization from the user, yet their stance leaves the following concerns unaddressed.
Third party applications can only ask for authorization after the user has already been yanked out of Safari. A rogue website, or a website whose client code may have been compromised by a persistent XSS, can yank the user out of the Safari browser. Since applications on iOS run in full-screen mode, this can be an annoying and jarring experience for the user.
Third party applications can only ask the user for authorization after they have been fully launched. To register a URL Scheme, application developers need to alter their Info.plist file. For example, here is a section from Skype?s Info.plist:
<key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleURLName</key> <string>com.skype.skype</string> <key>CFBundleURLSchemes</key> <array> <string>skype</string> </array> </dict> </array>
[Note: If you have a jailbroken iOS device and would like to obtain the list of URL Schemes for applications you have downloaded from the App Store, just copy over the Info.plist files for the applications onto your Mac and run the plutil tool to convert them to XML: plutil -convert xml1 Info.plist]
Next, the application needs to implement handling of the message in it?s delegate. For example:
(BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url
{
// Ask for authorization
// Perform transaction
}
Unlike the case of the tel: handler which enjoys the special privilege of requesting the user for authorization before yanking the user away from his or her browsing session in Safari, third party applications can only request authorization after they have been fully launched.
A solution to this issue is for Apple to allow third party applications an option register their URL schemes with strings for Safari to prompt and authorize prior to launching the external application.
Should Apple audit the security implications of registered URL schemes as part of its App Store approval process? Apple?s tel: handler causes Safari to ask the user for authorization before placing phone calls. The most logical explanation for this behavior is that Apple is concerned about their customers? security and doesn?t want rogue websites from being able to place arbitrary phone calls using the customer?s device.
However, since the Skype application allows for such an abuse case to succeed, and given that Apple goes to great lengths to curate applications before allowing them to be listed in the App Store, should Apple begin to audit applications for security implications of exposed URL Schemes? After all, Apple is known to reject applications that pose a security or privacy risk to their users, so why not demand secure handling of transactions invoked by URL Schemes as well?
Skype is just one example. Besides Skype, there are many additional third party applications that register URL Schemes that can be invoked remotely by Safari without any interaction from the user. See the following websites for a comprehensive list http://wiki.akosma.com/IPhone_URL_Schemes and http://handleopenurl.com/scheme.
List of registered URL Schemes not available to the average user. You can enumerate all the Info.plist files in your iPhone to ascertain the list of URL schemes your iPhone or iPad may respond to assuming you have jailbroken your iPhone. However, it may make sense for this list to be available in the Settings section of iOS so users can look at it to understand what schemes their device responds that can be invoked by arbitrary websites. Perhaps this will mostly appeal to the advanced users yet I feel it will help keep the application designers disciplined the same way the user location notification in iOS does. This will also make it easier for enterprises to figure out what third party applications to provision on their employee devices based on any badly designed URL schemes that may place company data at risk.
Note that in order to create a registry of exposed URL schemes, Apple cannot simply parse information from Info.plist because it only contains the initial protocol string. In other words, the skype: handler responds to skype://[phone_or_id]?call and skype://[phone_or_id]?chat but only the skype: protocol is listed Info.plist while the actual parsing of the URL is performed in code. Therefore, in order to implement this proposed registry system, Apple will have to require developers to disclose all patterns within a file such as Info.plist.
I feel the risk posed by how URL Schemes are handled in iOS is significant because it allows external sources to launch applications without user interaction and perform registered transactions. Third party developers, including developers who create custom applications for enterprise use, need to realize their URL handlers can be invoked by a user landing upon a malicious website and not assume that the user authorized it. Apple also needs to step up and allow the registration of URL Schemes that can instruct Safari to throw an authorization request prior to yanking the user away into the application.
Given the prevalence and ever growing popularity of iOS devices, we have come to depend on Apple?s platform with our personal, financial, and health-care data. As such, we need to make sure both the platforms and the custom applications iOS devices are designed securely. I hope this writeup helped increase awareness of the need to implement URL Schemes securely and what Apple can do to assist in making this happen.
If you liked this post check out SANS' new class on Secure iOS App Development.