This is because iOS has special URL handlers so when it encounters this:

<iframe src="tel://1-604-555-1212?call"></iframe>

in the code of a page, Mobile Safari hands that off to the phone application, but for very good reasons you have to confirm that you actually what to make a call.

Except if it’s Skype.

The same code, except using the Skype URL handler doesn’t ask permission, it just does it. So if this were in a page:

<iframe src="skype://1-604-555-1212?call"></iframe>

Your iOS device would launch Skype (assuming you have it installed of course) and just call.

No, that can’t work you say!

I wish that were the case, but it isn’t. From a post on SANS we learned about this vulnerability and we tested it. I made a simple (like took me 2 mins to create) web page that embedded the Google Voice number into the page with the skype: URL handler. I went to that page and … Skype came to the front, dialed and I was talking with Chad.

Simple as that.

Now, this might not seem like a terribly bad thing, but first off, Skype should have asked if I wanted to make the call in the first place. Second, Skype isn’t the only app that could have this problem. It seems that Apple feels the responsibility of what to do when something comes from Safari to an app is the app’s business not Apple’s. In fact, according to the SANS post, the app can’t do anything about the request until after the user leaves Safari. In other words, the Skype app would have to realize that the request was coming from Safari and interject with “Are you sure you want to call this number…”

I’m on the fence as to whether this is something that Apple should handle at the iOS level or be a mandate to app developers. All I know is that right now, the problem is there, and it isn’t hard to exploit and it isn’t easy to find out all the various URL handlers that are out there (here is the doc from Apple and “skype” isn’t in there).