Okay, so in iOS you can disable things. To protect the user, the device, the organization, from misuse, etc. One of the things you can do is disable Safari, so the end user can’t surf to anything bad. (I’m being a little snarky – there are some good cases where you’d want to prevent end-user web surfing: Gambling sites. Porn. Chat rooms. Competitors' tip sites. Stuff like that). It’s very easy, and appears to be very complete.

But yesterday I was testing something out and found an easy way around the restrictions. You can install what’s called a Web Clip to the iOS device (iPhone, iPad, etc.) That clip is basically a single web page, taken from whatever URL you configure when you create the clip. This clip goes on the main application screen of the device, just like a “real” application would, and allows quick and easy access to, well, just about anything. You could have a clip that shows a security dashboard. Or a weather report. Or list of important emergency contacts. Really, just about anything you could put into a web page.

The trick is that the device disables any links within that clip. So though you could display, for example, the front page of CNN, you couldn’t navigate to any of the links on that site. Or so I thought.

Turns out that some simple javascript methods aren’t properly trapped by the display engine. I found this while testing a web clip that pointed to the Google home page. As I entered terms into the search field, it instantly showed me similar searches in a drop-down list. It’s a pretty cool feature that I’ve grown to like. But what I didn’t expect was that I could tap on any of those suggested searches (or on the “I Feel Lucky” button), and that the clip would load the desired search results. I was able to navigate beyond the source of the web clip. For most pages, that was the end – I couldn’t navigate further. But some more “modern” web applications, like Gmail, worked just fine, as if I weren’t in a restricted browser at all.

So I dug a little deeper, and figured out how to replicate the behavior. I’m not sure if I’m using exactly the same method that Google did (their javascript code is notoriously obfuscated, and I’m definitely not a javascript expert). I’m sure there are other ways to accomplish this. But what I ended up creating was a simple document that uses window.location=url to replace the contents of the window with the contents of the supplied URL variable. Pretty simple stuff.

I looked around (via google, naturally) for any other writeups of this vulnerability, but couldn’t find any. So I wrote it up and posted it here, on the Intrepidus Group website.

If you’ve seen this before, or have any additional details or thoughts, or especially, suggestions for a workaround, please let me know. I can’t believe I’m the only person to have noticed this.