First impression on unpacking the Q702 test unit was the solid feel and clean, minimalist styling.
iPhone's Safari dials calls without warning, says researcher
- — 09 November, 2010 23:34
A security researcher is asserting that Apple has made a poor security decision by allowing its Safari browser to honor requests from third-party applications to perform actions such as making a phone call without warning a user.
Safari, like other browsers, can launch other applications to handle certain URL protocols. These might be in clickable links, or in embedded iframes.
An iframe containing a URL with a telephone number, for example, will cause Safari to ask if the user wants to make a phone call to that particular number, wrote Nitesh Dhanjani, a security researcher, on the SANS Application Security Street Fighter blog. Users can tap a button to make or cancel the call.
But Dhanjani found that behavior changes in some cases. For example, if a user has Skype installed and stays logged into the application, Safari does not give an alert when it encounters a Skype URL in an iframe, and immediately starts a Skype call, he said.
"In this case, Safari throws no warning, and yanks the user into Skype which immediately initiates the call," Dhanjani wrote. "The security implication 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)."
Dhanjani said he contacted Apple about the issue. The company said that third-party applications should be coded to ask permission before performing a transaction. But in the current arrangement, third-party applications can only ask for authorization after a person has been "yanked" out of Safari and the application has been fully launched, Dhanjani wrote.
"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," Dhanjani wrote.
He posed the question of whether Apple -- which maintains a fairly strict auditing of third-party applications -- should also check the URL strings before the applications are allowed to be distributed through its App Store.
"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?" Dhanjani wrote.
There are many other third-party applications that register URL schemes that pull a user out of Safari without any interaction.
It is possible to look at the URL schemes allowed by the iPhone and iPad on a device that has been jailbroken. But Dhanjani said it might be good to allow people to take a look at those URL schemes, since 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."
"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," Dhanjani wrote.
Apple could not be immediately reached for comment.