AppSec Blog

UI Spoofing Safari on the iPhone

This is the second in a series of guest posts from security researcher Nitesh Dhanjani. His first post was on Insecure Handling of URL Schemes in Apple's iOS. Nitesh will be giving a talk on "Hacking and Securing Next Generation iPhone and iPad Apps" at SANS AppSec 2011.

Popular web browsers today do not allow arbitrary websites to modify the text displayed in the address bar or to hide the address bar (some browsers may allow popups to hide the address bar but in such cases the URL is then displayed in the title of the window). The reasoning behind this behavior is quite simple: if browsers can be influenced by arbitrary web applications to hide the URL or to modify how it is displayed, then malicious web applications can spoof User Interface elements to display arbitrary URLs thus tricking the user to thinking he or she is browsing a trusted site.

I?d like to call your attention to the behavior of Safari on the iPhone via a proof of concept demo. If you have an iPhone, browse to the following demo and keep an eye out on the address bar:

For those who do not have an iPhone available, here is a video

And here are two images detailing the issue:

Figure 1: Image on left illustrates the page rendered which displays the ?fake? URL bar while the real URL bar is hidden above. Image on right illustrates the real URL bar that is visible once the user scrolls up.

Notice that the address bar stays visible while the page renders, but immediately disappears as soon as it is rendered. Perhaps this may give the user some time to notice but it is not a reasonably reliable control (and I don?t think Apple intended it to be).

I did contact Apple about this issue and they let me know they are aware of the implications but do not know when and how they will address the issue.

I have two main thoughts on this behavior, outlined below:

1. Precious screen real estate on mobile devices

This is most likely the primary reason why the address bar disappears upon page load on the iPhone. Note that on the iPhone, this only happens for websites that follow directives in HTML to advertise themselves as mobile sites (see the source of the index.html in the demo site above for example).

Since the address bar in Safari occupies considerable real estate, perhaps Apple may consider displaying or scrolling the current domain name right below the universal status bar (i.e. below the carrier and time stamp). Positioning the current domain context in a location that is unalterable by the rendered web content can provide the users similar indication that browsers such as IE and Chrome provide by highlighting the current domain being rendered.

2. The consequences of full screen apps in iOS using UIWebView

Desktop operating systems most often launch the default web browser of choice when a http or https handler is invoked (this is most often the case even though the operating systems provide interface elements that can be used to render web content within the applications).

However, in the case of iOS, since most applications are full-screen, it is in the interest of the application designers to keep the users immersed within their application instead of yanking the user out into Safari to render web content. Given this situation, it becomes vital for iOS to provide consistency so the user can be ultimately assured what domain the web content is being rendered from.

To render web content within applications, all developers have to do is invoke the UIWebView class. It is as simple as invoking a line of code such as [webView loadRequest:requestObj]; where requestObj contains the URL to render.

Figure 2: Twitter App rendering web content on the iPad.

The screenshot above illustrates web-content rendered by the fantastic Twitter app on the iPad. To create this screen-shot, I launched the Twitter app on the iPad and selected a tweet from @appleinsider and clicked on the URL in the tweet. Notice that the URL of the actual page being rendered is no where to be seen.

In such cases, it is clear that developers of iOS applications need to make sure they display the ultimate domain from which the application renders web content. A welcome addition to this would be default behavior on part of UIWebView to display the current domain context in a designated and consistent location.

Given how rampant phishing and malware attempts are these days, I hope Apple chooses to not allow arbitrary web applications to scroll the real Safari address bar out of view. In the case of applications that utilize UIWebView, I recommend a designated screen location label only accessible by iOS that displays the domain from where the web content is being rendered when serving requests via calls to UIWebView. That said, I do realize how precious real estate is on mobile devices and if Apple choses to come up with a better way of addressing this issue, I'd welcome that as well.

If you liked this post check out SANS' new class on Secure iOS App Development.


Posted November 29, 2010 at 11:57 PM | Permalink | Reply

Dan Hummon

Sorry, nevermind; it's not that important. Please delete my previous comment. I was just a little annoyed. -Dan

Posted November 30, 2010 at 12:58 AM | Permalink | Reply

Dan Hummon

Actually, you should look at my version of the exploit as well. With a bit of added javascript, you can keep the real title bar hidden quite effectively.

Posted November 30, 2010 at 1:20 AM | Permalink | Reply


This is the major problem with using frameworks, it becomes very easy to duplicate user experiences and that is how humans build evidence chains of trust. Cocoa NS or UI objects can easily be used to create look-a-like installers and app's. I have been surprised this has not happened in mass scale. (Did a test a while back and found many mac users all to happy to install items as long as the installer looked and behaved as described in Apple Human Interface Guidelines, iOS users would most likely meet the same fate.) Developers must make sure that some kind of validation and verification methods are used and part of the user experience, in this case we see the failure in the Lock Icon as part of that experience.
I also think we need to keep this in mind''
Nothing is as simple as it looks, we just need to be aware of the risk. How the evidence chain of trust is establish by the user's familiarity with the GUI. Spear fishing in my view is a failure of education in the organization or user. Near perfect counterfeit applications as the spear tip is a excellent point to raise. Know your sources, if you install it make sure the evidence supports the level of trust the app requires to run. (Android users need to understand this as well.) If you cannot verify then move on, just like you do in life. If you really want to get crazy think of all the companies that install open source code but never look at the source. Walk into any IT department and look at the tools they may have, can you with little effort create counterfeit, sure. How do you defend? Evidence chains + Risk management.
Apple has done a good job with the App store validation process. (One day we may see this become a problem when a rouge app is loaded up there, for now I think JailBroken phones are risk multipliers.) I think you really do raise some great points and we all should understand the functional and non functional aspects of the risk.
Nice Job and good points'' Out

Posted November 30, 2010 at 4:50 PM | Permalink | Reply


Maybe this is simple-minded, but perhaps a distinction could be made between HTTP and HTTPS URLs? If a site requires SSL, then the address bar should be displayed to confirm its identity. Of course, that won't do anything to save people who think is the real site, but it's a start.

Posted November 30, 2010 at 8:14 PM | Permalink | Reply


Peter ''" that doesn't solve the issue at all ''" the fake site won't be HTTPS, and will just display a fake address bar to make it look like it is!
Think it through''..
If anything your solution makes it EASIER to trick users, because they will see the visible address bar
as'confirmation' that the site is real.

Posted December 21, 2010 at 12:52 PM | Permalink | Reply


thanks for the good article

Post a Comment - Cancel Reply


* Indicates a required field.