Insecure Handling of URL Schemes in iOS

Published: 2010-11-09
Last Updated: 2010-11-09 20:11:12 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

Nitesh Dhanjani posted a nice blog post as part of the SANS Application Security blog [1]. He discusses a particular interesting vulnerability in iOS. In iOS, like in other operating systems, application may register themselves to handle particular URL schemes. For example, a URL starting with "tel:" links to the telephone application.

However, how these URL schemes are dealt with depends on the application receiving these requests from the browser. The telephone application will for example prompt the user asking if it should dial the number. Skype on the other hand does not prompt the user. In order to prompt the user, the application has to fully load and start up. So at the very least the attacker may be able to load the application.

Desktop browsers, like for example Firefox, will first prompt the user for these external URL schemes (try "telnet:", which will launches a terminal and open telnet in most cases).

[1] https://blogs.sans.org/appsecstreetfighter/

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
3 comment(s)

Comments

Is this such a big issue ? Why should the source app ask ? It is the destination app aka URL handler, that knows about the URL and can pop up the relevant warnings.
My browser / game whatever app can only see a URL that is supposed to be handled externally.

Skype is to blame, but the more calls the badware makes, the more money they earn. And their prices for SkypeOut is already crazy, like double of going VoIP SIP rates.
Sure it is an issue. The browser should ask before launching an external application, otherwise if an application were to be found to be vulnerable to attack, a malicious attacker could cause the vulnerable application to launch via drive-by. This doesn't mean the target application shouldn't also prompt before taking certain actions.
I see no reason that the browser should even load any iframe URL that isn't http:// or https://. Anything other than HTTP should require user interaction.

Diary Archives