Have you ever clicked a phone number in Safari to get the phone app to call that store you were searching for? Maybe you’ve clicked a link to a YouTube video and it opened in the awful YouTube application instead of Safari. In iOS, this interaction between apps happens via URL schemes, which are available to Apple applications as well as third party applications. Everyone uses them without noticing they exist, just like file-type associations on PCs.
### URL Schemes
Out of the box, iOS provides URL schemes for things like HTTP, email, text messaging, maps and telephone numbers. These URL schemes allow iOS to convert strings of text into actions, allowing time saving features like clicking a phone number in Safari to initiate a phone call.
Third party applications use these schemes to enable workflows across apps. Each application can register its own custom handle and scheme. The scheme is how applications interpret the input. The handle is the prefix to URLs that will launch the app, registered with the system.
A sample handle for a Great Application(TM):
GreatApplication://
[X-Callback-URL](http://x-callback-url.com/), a draft specification created by Greg Pierce of Agile Tortoise, has been created to allow two-way communications by applications. It allows sending an action to an application that will return a result back to the original application.
When the URL is opened, iOS launches TargetApp and passes the URL as arguments (see implementation for details of handling incoming URLs). TargetApp will parse the URL, identify the action requested, and translate “Hello” to “Spanish” as passed in the parameters. The “translate” action and its parameters are all specific to TargetApp and should be documented by the developer. If TargetApp is successful in translating the word, it calls the URL in the x-callback parameter to return the result to SourceApp.
### Usage
Applications such as Tweetbot use URL schemes both by providing a scheme to perform actions in Tweetbot and by configuring actions that use other applications, such as sending a photo to Camera+ for editing before tweeting.
Most users have therefore used these URL schemes without knowing they exist, and advanced users take advantage of them to make iOS more powerful and friendly to workflows that would be otherwise unavailable.
Some great examples of advanced workflows can be found in applications such as [Drafts](http://agiletortoise.com/drafts/), [Launch Center Pro](http://contrast.co/launch-center-pro/) and [Editorial](http://omz-software.com/editorial/).
Launch Center Pro gives you a catalog of actions to pick and set shortcuts for. Using Launch Center Pro, you can quickly send a new task to OmniFocus, launch Camera+ in “Take a Picture” mode, append a string of text to a file in Byword and much, much more. Drafts works in a similar fashion, allowing you to create actions based on your text input.
### Issue
URL Schemes are great. They are, however, a source of user input that should never be trusted as safe. To allow convenience without creating a security or privacy risk to the user, any application registering a custom scheme must keep in mind that input could be sent by an attacker.
Safari for iOS, being a web browser, can be used to send actions to applications that implement URL schemes. The easiest way to test this is to find an application on your device supporting URL schemes, building an action in Launch Center Pro, and copying that URL in Safari. Here are a few samples you can try. You must have either WhatsApp or Felix installed for these examples to work.
Launching WhatsApp will prompt you to pick a contact and show you a message ready to be sent with the word “Test”.
**Warning: Clicking this on iOS will launch WhatsApp and prompt you for a contact to send “Test” to**
[Try it.](whatsapp://send?text=Test)
whatsapp://send?text=Test
Launch Felix, which will show a precomposed message ready to be sent.
**Warning: Clicking this on iOS will launch Felix with a message sheet with the text “Testing a few URL scheme things out…”**
[Try it.](felix://compose/post?text=Testing%20a%20few%20URL%20scheme%20things%20out…)
felix://compose/post?text=Testing%20a%20few%20URL%20scheme%20things%20out...
Not only will Safari prompt you before launching the app, these two actions are built in a way where time is saved, but no action is actually performed automatically. You still have to send the message yourself.
As applications implement actions, it’s easy for a developer to only think about the ease of use of an action and to be tempted to automate it as much as possible, especially if the goal is to use X-Callback-URL to send the user back to his original application.
Compounding the issue is the fact that *Safari will launch these URLs automatically* if they are placed in an inline frame. This frame would perform the same action as the Felix example above, automatically.
<iframe src="felix://compose/post?text=Testing%20a%20few%20URL%20scheme%20things%20out..." height="240" width="320"></iframe>
In the case of well-built actions that require a user confirmation or that do not present a risk, this has little impact. But combined with a dangerous action, it makes automating an attack all that much easier.
I sat down at the end of August and looked at the applications I had on my phone and found two examples of dangerous actions within a few minutes.
### Example 1 – Data destruction in Byword
Byword allows a file to be overwritten through its URL scheme. The action is called “Replace File” and does exactly as it says: It replaces the file named ‘FilenameX’ with the new text you feed it. This string would overwrite ‘Important.txt’ with the string “haha”. For most users, recovering the data is impossible.
byword://replace?location=icloud&path=&name=Important.txt&text=haha
The only thing that mitigated the risk of this vulnerability being exploited is the fact that a file path and name is needed. However, with iCloud being flat, it is not so far fetched to imagine a person would have a file called ‘important.txt’ or ‘todo.txt’. In a targeted attack, someone could try to make an educated guess for a filename. If you sent me a file called ‘bigproject.txt’ and I know you are a Byword user it would be logical to assume you store that file in iCloud. Dictionary attacks could possibly be performed, though a good distribution method for the malicious pages would need to be obtained, as Safari will only launch the first URL targeting an application. By using social media, instant messaging or email, an attacker would distribute the URL to a page with an embedded inline frame designed to overwrite the file. The same method could target a whole population of users by performing a *watering hole* attack. Watering hole attacks consist of targeting a site known to be a frequent destination of your targets. If you were attacking Apple fans, any of the big Apple blogs vulnerable to a cross-site scripting attack would be an enticing target.
[Metaclassy](http://metaclassy.com) responded quickly when I reported this issue and implemented a very good fix by prompting the user before overwriting a file.
[More details on this vulnerability.](http://blog.binaryfactory.ca/2013/09/cve-2013-5725-byword-for-ios-data-destruction-vulnerability/)
### Example 2 – Leak a user’s identity in Tweetbot
Tweetbot is my favorite Twitter client on iPhone, iPad and OS X. It supports multiple actions through its custom URL scheme, including following a user or marking a tweet as a favorite.
This can be useful to add a link for users to follow you easily, but no prompt was presented to the user. This effectively means that you could get a Tweetbot user to follow you without them realizing. While this might seem minor, it is actually an important privacy risk. Imagine you are browsing a website, and an attacker either gives you a link to a malicious page or inserts the malicious inline frame in one of the pages. You barely have time to notice it and Tweetbot opens and follows someone. Once this has happened the person can now link you, or at least your Twitter account, to someone browsing that site or having received that email with a malicious link. As a lot of people, myself included, post enough details on social media to reveal our real identities, this could be used by attackers to reveal the true identity of anonymous users of a website, forum or email address. A political activist using an email account created only for this purpose could be revealed the moment he clicked on the malicious link.
The same can be done by having you favorite a tweet. Remember that Twitter can send notifications for such events, so even if you quickly unfollowed or un-favorited, the damage has been done.
In this image, you can see me receiving a phishing email. When I click the link, it opens Safari, which launches Tweetbot and has me following Justin Bieber.
How embarassing is that?
Tapbots has fixed this issue in Tweetbot V3 for iPhone, and fixes for the iPad and Mac version are coming. For the Mac, there’s a workaround which is to simply disassociate your browser from Tweetbot, as it is not using system-level handles like on iOS. If you’re on iPad, you can still try it out.
**Warning: Clicking this on iOS or OS X could cause you to follow me**
[Try it](tweetbot:///follow/gepeto42)
[More details on this vulnerability.](http://blog.binaryfactory.ca/2013/11/cve-2013-5726-tweetbot-for-ios-and-mac-user-disclosureprivacy-issue/)
### Conclusion
URL schemes will become more popular as developers try to get applications to communicate and enable great workflows. Some were expecting new official methods of app communication in iOS 7, which this has not materialized. Because of that, URL schemes are currently the only practical way for inter-app communications on iOS. As these schemes become more popular, it is important for developers to remember that input from URL schemes could be malicious. Developers should ensure that any action with the potential to damage data, threaten privacy or reveal confidential information should be confirmed by the user before being performed.
If you want to play with URL schemes, I highly recommend using Contrast’s [support site](http://actions.contrast.co/) for Launch Center. Look at the applications you have and how they behave when you send them a potentially dangerous request for action. If you find something, notify the developer before disclosing the issue publicly.
As more users attempt to centralize their computing lives, by replacing their laptops with iOS devices, it is only natural to want better interoperability between apps without interruption. Developers will have to add more support for URL schemes until better methods of inter-app communication are supported by Apple.
I have a gut feeling that there must be some calendar applications that can set up unwanted alarms at 3am, without the user noticing. There must be text editors that silently overwrite data. Surely there are messaging apps that send messages without the user’s consent.
Now we just have to find them.
***
*This was a guest post from Guillaume Ross, an Information Security Consultant, whose writing can be found at [Binaryfactory.ca](http://blog.binaryfactory.ca). If you think you have an article to contribute, [get in touch](http://brooksreview.net/contribute/).*