iPhish: Phishing Vulnerabilities on Consumer Electronics

Yuan Niu, Francis Hsu, Hao Chen

University of California, Davis

Abstract refrigerators 2 .
As web-capable devices make their way into con-
As consumer electronic devices with embedded browsers
sumers’ hands, services, such as banking and shopping,
become popular, financial institutions and online mer-
are being adapted for these new platforms. For exam-
chants set up websites to accommodate visitors using
ple, Bank of America [2] and Amazon [1] have intro-
these devices. These devices range from cell phones
duced websites for mobile devices, indicating the emerg-
to gaming consoles, cars, and even refrigerators. Port-
ing paradigms of e-commerce on less traditional comput-
ing a traditional desktop1 browser to a mobile device
ing devices.
is more involved than resizing the display. To adapt to
the hardware limitations inherent in mobile devices, mo- However, adapting websites and web browsers for
bile browsers often remove or replace certain features consumer electronic devices may introduce unexpected
commonly found in traditional browsers. Unfortunately, security vulnerabilities. Due to hardware limitations on
some of these features are critical for depending against these devices, browsers often have to remove or replace
phishing attacks. We studied browsers on three mo- features. If users rely on these features for detecting
bile devices and discovered vulnerabilities in their input, phishing websites, the users will be more vulnerable to
chrome, and URL display. We conducted a user study to phishing on these browsers. For example, due to typi-
confirm our findings on the iPhone Safari browser, one of cally small display sizes on these devices, their browsers
the most popular mobile browser platforms. For each po- may hide, or allow the web page to hide, the URL bar
tential vulnerability, we were able to construct a phishing or the status bar. Even when they display URLs, they
scenario to successfully fool users into giving away the truncate long URLs to fit within the screen width. Since
credentials for a role-played Bank of America account. the ability to read and vet URLs is crucial for defend-
To mitigate the vulnerabilities, we propose to designate ing against phishing attacks, without this ability ordinary
and display URLs in a more phishing-resistant way, and users who have trouble parsing URLs are still just as
to create an anti-phishing proxy that is independent of prone to phishing, and even expert users who can parse
mobile devices or browsers. URLs will find it more difficult to detect phishing web-
sites. Moreover, certain convenient features on desktop
or laptop computers encourage users to use web browser
1 Introduction in a way that is less vulnerable to phishing. When con-
sumer devices remove these convenient features, often
Web browsers started as applications running on desk- due to physical limitations, users tend to behave in ways
top and laptop computers. Users sat in front of a rela- that are more vulnerable to phishing. For example, many
tively large screen with a keyboard and mouse. Today, consumer electronic devices replace physical keyboards
the web is evolving into a general computing platform with soft keyboards on the screen. Since typing on these
where the user can access most of his computing re- soft keyboards is often unfamiliar, slow, and inaccurate,
sources. Due to the popularity and ubiquity of the web, users are discouraged to type URLs manually, which is
web browsers reach beyond traditional desktops and lap- less vulnerable to phishing, and are encouraged to follow
tops to enter many non-traditional computing platforms, links, which are more vulnerable to phishing.
such as mobile phones (e.g., iPhone), video game sys- We examined three consumer electronics devices:
tems (e.g., Nintendo DS and Nintendo Wii), and even
2 http://us.lge.com/products/model/detail/
1 Forthe sake of succinctness, we refer to browsers run on desktop home\%20appliances_refrigerators_side-by-side_
and laptop machines as simply “traditional browsers.” LSC27991.jhtml

1
iPhone, Nintendo DS, and Nintendo Wii. We identified as if the URL bar is part of the webpage content. The
their hardware limitations, their browser limitations, and Nintendo Wii automatically hides URL bar completely
the impact of the limitations on phishing attacks (Sec- when displaying the page content.
tion 2). Then, we set up a user study to evaluate the vul-
nerability of users to phishing attacks on iPhone (Sec- 2.2 Input
tion 3). We describe the findings from our user study
in Section 4. Finally, we propose approaches for both Without the traditional input devices of keyboard and
browsers and mobile websites to mitigate phishing at- mouse, these platforms require the user to navigate by
tacks (Section 5). pointing. The iPhone and Nintendo DS both use a touch
screen interface while the Nintendo Wii uses a wand con-
troller to point at the screen controls. They all use an on-
2 Devices screen keyboard that allows users to peck out input text
We examined three consumer electronics products: characters one by one. Compared to using a keyboard,
iPhone, Nintendo DS and Nintendo Wii. The iPhone inputting text in this manner is stranger, slower, and less
runs a modified version of the Apple Safari browser, precise.
while the Nintendo DS and Wii use modified Opera
browsers. The modifications to the browsers accommo- 2.3 Software Updates
date the limitations inherent to the new platforms, as de-
All three browsers currently run on restricted software
scribed below.
platforms, which limit the applications that can run there.
While this restriction may be motivated by security since
2.1 Display it may prevent malware from attacking the system, it also
The modified browsers run on platforms with dis- prevents the user from adding useful software, such add-
plays that are much smaller than those used for desktop ons that customize or extend the browser. Furthermore,
browsers. While typical desktop browsers run on dis- users cannot apply security updates to these browsers as
plays of 1024x768 pixels or larger [10], the displays of easily as to desktop browsers. The iPhone requires its
the devices that we examined are smaller due to portabil- user to dock it with a computer to apply software up-
ity or compatibility constraints. Table 1 lists the display dates [5]. The Nintendo Wii requires navigating through
resolutions of the platforms. Note that the total display a lengthy setup menu. The Nintendo DS distributes its
area is at between 12.5%-40% of a desktop browser. browser software only on a read-only memory cartridge,
thus preventing updates from the Internet completely.
Platform Display Resolution
Apple iPhone Safari 320x480 3 User Study Setup
Nintendo Wii Opera 640x480
Nintendo DS Opera 256x384 We conducted a study to compare users’ reactions to
similar phishing scenarios on a desktop Safari browser
and the iPhone Safari browser. We recruited three groups
Table 1: Maximum display resolution of devices of 37 participants total:
A browser window normally consists of control 1. Unscreened users. We recruited 11 unscreened
menus, status displays, a current URL display, and con- users, from Facebook, Craigslist, and flyers.
tent pane of the current site. Since a user primarily in-
teracts with the content pane, it logically follows that a 2. Knowledgeable users We recruited 6 knowledge-
browser would maximize the content pane at the expense able users from undergraduate computer science
of other elements on the browser window, in response to classes who had heard the term phishing and who
the display limitation. For example, traditional browser knew what indicators to look for in identifying
chrome elements (the portions of a browser window that phishing attacks. Four of our participants owned an
do not display Web page content) normally hold the en- iPhone or iPod touch. Out of the four, two were able
tire URL of the displayed site unless the URL is unusu- to detect phishing attacks, and the other two failed.
ally long. The Nintendo DS reserves a small fixed 256 3. Expert users We recruited 20 expert users from a
x 15 pixel bar at the top of the display for the URL, dis- graduate-level computer security class. As an indi-
playing about 22 characters across in a small font. The cation to their security sophistication, all but three
iPhone uses a 320 x 60 pixel bar for the URL, but the identified all the phishing attacks.
URL text only occupies an area 240 pixels across. More-
over, iPhone’s URL bar can be scrolled off the browser To protect the privacy of our participants, we created a
windows, either by the user or by a script in the webpage, fake persona and cloned the mobile and desktop versions

2
of the Bank of America website. We modified the DNS a further barrier, scrolling through the URL manually is
setting to route all requests for bankofamerica.com to our available only in URL input mode on iPhone.
cloned sites. We changed settings in the desktop Safari The users’ instructions included an admonition in-
browser to suppress certificate warnings but were unable tended to alert to the fact that they should be concerned
to do so on the iPhone. We instructed the participants with security: It is NOT NECESSARY to complete each
to play the role of a user, and to access the user’s Bank task. Only complete the task if it DOES NOT compromise
of America and Facebook accounts using the credentials the security of Neo’s account information.
that we provided.
Before the user started the tasks, we gave them a brief
tutorial of the iPhone’s features. Specifically, we high- 4 Vulnerabilities
lighted the thumbnail view’s display of the page title and
URL, and how to switch between landscape and portrait The need to conserve screen real estate on the iPhone
modes. led to the sacrifice of browser chrome features in Safari.
We asked users to perform a series of tasks involving There is no bottom status bar because the iPhone does not
a Bank of America account on both the iPhone Safari support mouseover() events. If a user holds down the
browser and the desktop Safari 3 beta browser. The first link for a few seconds, they see the destination URL in
tasks on both browsers was to log into the “real” Bank of a hover text. The static bottom bar contains navigation
America websites and record an account balance. This buttons, bookmarks, and thumbnail views. We examine
was intended to be a control task to familiarize users with some specific points of weakness below and present sce-
the process of logging in and to show them what the real narios in which these weaknesses could be exploited.
Bank of America website looks like. After performing
the control task, we asked the users to check a Gmail ac- 4.1 User Input
count for further instructions via e-mail. The user first
did the tasks on a laptop using the Safari 3 browser and Typing is a tedious and often inaccurate process for
then continued the tasks on iPhone Safari browser. We users not accustomed to such a tiny touch screen touch-
maintained the order so that users could have a chance pad. Because of this, it is tempting to follow links in
at recognizing the more obvious phishing tactics in a fa- e-mails rather than typing the links manually. Every user
miliar environment before moving on to similar tasks on new to the iPhone in our study expressed frustration with
a new device. We hoped to prime the users by alerting typing, especially in password fields.
them of possibly suspicious behaviors. Additionally, the iPhone provides no shortcuts to
On the Safari 3 browser on the laptop, we instructed quickly switch from one application to another. To
the user, via emails, to visit the following phishing web- switch from Mail to Safari, for example, the user must
sites: click to go back to the main screen, which needs time
to render, and switch to a new application, which must
1. A website that hides the browser’s URL bar. load, taking at least two clicks. Switching from a mail
2. A website with an incorrect domain. application to a browser on a computer or laptop, how-
ever, requires no more than one click or a simple Alt-
On the iPhone, after visiting the above websites, the Tab or Apple-Tab almost instantaneously. Even switch-
user was instructed to visit the following phishing web- ing between browser windows on the iPhone is more
sites to exploit iPhone specific weaknesses: complicated. iPhone users must first initiate thumbnail
1. A website that displays a fake browser chrome. mode and choose the correct window, clicking at least
2. A website with an incorrect domain and a long URL once and scrolling through at least one other window,
such that the displayed URL in iPhone fails to show and tapping on that window. A click of the mouse or
the incorrect domain (Section 4.2.1). another Alt-Tab/Apple-Tab, again, performs this sim-
ple task on the desktop browser almost instantaneously.
We did not create desktop versions of these iPhone On the iPhone, switching windows from one application
websites because they exploit problems we think are to another, or even within one application, is a much
iPhone specific. Duplicating the chrome of a desktop longer and more complicated process than its equivalent
browser on a website convincingly is considerably harder on desktops. Users who value convenience have great
for phishers than duplicating the chrome of the iPhone temptation to follow links from other applications.
browser. As for long URLs, a typical desktop browser Five average users said they would not usually follow
has at least 800 pixels for text in the URL bar, and users links in emails on desktop computers, but that typing
can use a mouse to easily scroll through the URL. Given in the iPhone browser was “annoying”. Moreover, the
the relatively small width (less than 400 pixels) of the iPhone made it more tempting for them to click the links
URL bar on the iPhone and the lack of any input devices provided in emails when they faced with the tedious al-
besides fingers, users cannot see the entire URLs. As ternative of reading an e-mail, observing the link, nav-

3
igating to the home screen to reopen Safari, and finally which is untrusted — is truncated in the URL bar.
typing the URL. The URL bar uses about 50 pixels to display the
http:// or https:// portion of the URL. Assum-
ing a conservative estimate of 10 pixels per letter, to
4.2 URL Display
hide phishydomain.com in portrait mode, we need
4.2.1 URL Truncation a subdomain name of about seven letters to prepend
to bankofamerica.com.phishydomain.com
A fundamental flaw in the iPhone Safari browser lies because bankofamerica.com uses about 170
in its URL display. All URLs too long to fit on one line pixels. In instances where the SSL lock icon appears,
are truncated. In thumbnail view (Figure 1(a)), a substan- subdomain names can be even shorter.
tial middle portion of the URL is truncated and replaced
with an ellipsis with no way to expand the truncated por-
tion of the URL. The only way by which a user can view
the entire URL is to go back to the URL input and man- 4.2.2 Address Bar
ually scroll, letter by letter, through the URL. In hover
view, the middle portion of the URL is truncated in the
same way as in the thumbnail view (Figure 1(b)). Fur- As a feature to maximize the screen space for con-
thermore, the onhover destination link is displayed after tent, the iPhone Safari browser scrolls the address bar
a few seconds of holding down the link. Upon release, along with the page content. Web page creators can also
the hover action may still be interpreted as a click if the use a Javascript scrollTo() trick to hide the URL
user lifts rather than slides the finger away from the link, bar on page load by jumping to a predetermined loca-
causing the browser to load the phishing page. tion within the page. According to the iPhone user man-
ual [5], tapping on the status bar at the top of the screen
brings the user back to the top of the page, but the same
scrollTo() trick can be used with DOM information
to always jump to a predetermined location once the user
scrolls too close to the address bar. This, in effect, nulli-
fies the built in function to show users what URL they’re
at. Users can still view the URL in thumbnail mode,
however.
(a) Thumbnail Mode
The iPhoneWebDev Google group 3 contains guides
and threads discussing various way to hide the URL bar.
One developer, listed “Hiding the URL bar ... more per-
manently” as the third priority point 4 to bring up with
Apple iPhone developers at a tech talk.
Hiding the URL bar on page load is widely used and
(b) Link Hover accepted, as evidenced by the Bank of America 5 , Ama-
zon, and Facebook mobile versions. A phisher can easily
Figure 1: Display of truncated URLs take advantage of this by hiding the URL of the page on
page load. To fool users who are more vigilant and ob-
servant during page load, the phisher can use a very long
An attacker from a rogue domain wishing to im- URL or a URL with a slight difference, such as “vv” in
personate a legitimate domain may simply construct place of “w” or “1” in place of “l.” In our user study task
a long URL that uses the legitimate domain name as that hid the URL bar, none of the average users or knowl-
a subdomain name. For example, a phisher wishing edgeable users was alerted by the missing URL bar and
to deceive Bank of America users could construct proceeded without verifying the URL. When asked about
a website on phishydomain.com by creating this during debriefing, one user responded, “It hampers
a subdomain ending with bankofamerica.com the usability to always check.” The same user noted that
and using long filenames as in the following because he could not see the URL, it “did not allow the
URL: subdomain.bankofamerica.com. room to be suspicious.”
phishydomain.com/longfilename. The
attacker can select the string subdomain in the
3 http://groups.google.com/group/iphonewebdev
above URL such that the beginning part of the URL 4 http://groups.google.com/group/iphonewebdev/
— subdomain.bankofamerica.com, which browse_frm/thread/e98bcb426a036d3a
appears legitimate — is displayed in the browser’s URL 5 The mobile version of Bank of America we spoofed was a general

bar but the next string — .phishydomain.com, mobile version, and not the new iPhone version.

4
4.2.3 Weaknesses in the Opera browser and further customize that software with add-ons and
bookmarks. Users of the iPhone browser can only add
In our examination of the Opera browser on the Nin-
bookmarks, which are displayed from a button on the im-
tendo DS and Wii, we noticed problems in the URL
mutable bottom menu.
display. Although banking from a gaming console is
An attacker can easily compromise the use of the ad-
currently rare, it may become popular with the release
dress bar as a location indicator by a simple Javascript
of a keyboard. As an indication, financial transactions
scrollTo() trick described in Section 4.2.2. The trick
are already taking place through gaming consoles on the
can force the page to jump back to the location of the
XBOX Live network and Wii marketplace.
fake URL bar on the webpage. However, this trick also
As shown in Figure 2, the Wii Opera browser simply
causes the page to behave strangely when a user attempts
does not display the URL with the current page at all.
to scroll manually, because the page always jumps back
The is no way to preview the destination of a URL link
to the top automatically, and the user can defeat this
on a page. To view the current URL of a page, the user
trick by checking the page’s URL in the thumbnail view.
must take an extra action and click on the page informa-
When users encountered the strange scrolling behavior,
tion button on the chrome toolbar. The information page
however, they consistently tried to complete the task and
displays the page address on one line. The user must
made no comment except to express annoyance. One, for
manually scroll through a URL that cannot fit in one line
example, wrote “Hate interface” as feedback. Another
of the display width. Information about encryption being
user was unusually tenacious and typed in the password
used by the page is left out of the URL since it lacks the
despite having trouble seeing the form field as a result of
http/https portion.
the odd scrolling behavior.
Users from all groups, even expert users, who identi-
fied the URL as phishing by looking at the URL, failed to
notice the fake address bar sliding over the real one very
quickly on page load. Average and knowledgeable users
who tried to proceed in this stage should have noticed
it multiple times, but none did until it was specifically
pointed out in the debriefing stage.
Creating a false address bar is also quite easy: simply
using HTML and Javascript within the page, a phisher
can replicate all the features of the address bar except
for the “Add Bookmark” button. While no users actu-
ally tested this feature, we believe that omitting this fea-
ture will cause users to believe that it is an iPhone glitch
based on their feedback in encountering scrolling prob-
lems. Figure 3 shows the real iPhone chrome and our
fake chrome.
In our user study, even expert users admitted how con-
vincing the fake chrome looked. One expert user ad-
mitted that had he not been primed by prior instances
of phishing, he would have fallen for the fake chrome
trick. Another expert user simply wrote “I was fooled.”
Only one user, out of all 37, examined the chrome closely
enough to realize that it was fake. He commented that the
SSL lock icon in the address bar did not look quite right.

4.4 SSL
Figure 2: The Opera Wii Browser display and informa-
tion page When a user navigates to a site that does not have a
correct SSL certificate, the Safari browser pops up a short
dialog with options to either continue or abort. There is
no option for the user to examine the certificate and no
explanations provided as to why the certificate is invalid.
4.3 Chrome Simplicity
Although the URL bar displays a lock icon when the
Compared to a traditional browser, the iPhone Safari page loaded uses SSL, average and knowledgeable users
browser’s chrome is relatively easy to game. Users of still tended to look for a lock icon within the rendered
traditional browsers can choose the software they use HTML page.

5
 5 Mitigation
Since browser users on consumer electronic devices
are more susceptible to phishing attacks, browser devel-
opers, website designers and users should take steps to
mitigate the attacks. In this section we propose these ap-
proaches.
(a) Real Chrome

5.1 URL Designation and Display

To make phishing more difficult, website designers
can create more recognizable sites, and web browsers can
make the origin and authenticity of the site more appar-
ent to the user.
One focus point for website and browser designers is
(b) Fake Chrome
the URL since it reliably identifies the domain of a page.
Website designers can help by shortening URLs so that
Figure 3: Side by side comparison of the real iPhone
they appear completely on short URL bars on consumer
chrome with our fake chrome.
electronic devices. This could also help users parse and
evaluate the authenticity of the URL. The iPhone Safari
browser could be improved if more screen real estate is
Expert users refused to proceed on tasks after noting sacrificed so that the address bar is a permanent part of
the lack of SSL. They also refused to proceed when they the chrome. Prohibiting webpages from tampering with
encountered an invalid certificate error. They complained the URL bar would prevent them from hiding the bar
repeatedly that because there was no way for them to and displaying a fake URL in the page. When a long
check the details of a certificate, they were not comfort- URL exceeds the width of the URL bar, the iPhone Sa-
able proceeding. Average and knowledgeable users, on fari browser should scroll the URL, as what the desktop
the other hand, ignored the invalid certificate error. Only browser does, instead of truncating the URL to prevent
two average users did not proceed after seeing the SSL the attacker from hiding their malicious domain name
error. in the URL. If truncation is unavoidable, the URL bar
The SSL error affected just the first task directly, since should display the most important part of the URL, typ-
subsequent tasks were designed to test the effectiveness ically the second level domain (e.g. bankofamerica
of our spoofing. It served to penalize us because it should in www.bankofamerica.com), that helps establish
have acted as a primer to warn users of possible phishing the real identity of the website.
attempts. Nevertheless, it was not enough to deter most
non-expert users. 5.2 Proxies
One way to shrink the gap between desktop and mo-
4.5 Mail Application bile browsers is to bring plugins and more processing
power to the consumer mobile devices. Since it is diffi-
We used Gmail for all our emails. We discovered cult to upgrade the hardware of these devices, we accom-
that while the browser based version of Gmail performed plish the above goal through a proxy service that is in-
phishing filtering and injected a warning in red, the dependent of mobile devices’ platforms and browsers. A
iPhone Mail application did not. If users do not exam- major limitation of the iPhone and other mobile browsers
ine email headers, the version of the phishing email in is the difficulty or inability for users to download up-
the iPhone Mail application contains a seemingly valid dates and plugins. We have designed an Internet Content
sender address without any warnings. The iPhone Mail Adaptation Protocol (ICAP) [4] server to be used with a
application also does not strip suspicious link tags, while standard web proxy to protect users from phishing sites.
the browser based version of Gmail does. This, in combi- Our proxy service requires a one-time configuration in
nation with a long URL, can spoof a real online banking the browser to pass requests through the proxy server in-
e-mail notice convincingly. While this problem is not stead of directly retrieving pages. The proxy server then
specific to the iPhone, it is harder to mitigate. Desktop passes the request and fetched page contents to the ICAP
mail clients can use plugins and user defined filters, but server for processing. In the ICAP server we can run
the iPhone Mail application is immutable except when anti-phishing filters against the URLs, page content, or
Apple releases firmware upgrades. user context. The filters can be based on well-known

6
anti-phishing tests used in browser toolbars or search en- these passive hints [16]. Egelman found that users do
gine result filters. These anti-phishing filters are written pay more attention when their focus is interrupted with
as plugins to the ICAP server and can be composed ar- active warnings and were less likely to be fooled [13].
bitrarily. We can even allow the user to choose which Both Microsoft Internet Explorer 7 [6] and Mozilla Fire-
checks or transformations be made to the pages eventu- fox 2 browsers [3], provide these active warning for con-
ally delivered to the user. firmed phishing websites. While non-desktop browsers
Deploying a web-based proxy gives users the flexibil- currently can not make use of these anti-phishing tools,
ity of choosing whether to filter their Web destinations. this influenced our proxy design to help protect these
For sites that pose minimal risk to the loss of the user’s browsers.
credentials, or if users wish to bypass the proxy, it is un- While it is difficult to have users to identity and
necessary for those URLs to undergo the same process- react appropriately to phishing sites, automated tech-
ing as more important sites for banking or shopping. niques can identify phishing sites with high accuracy.
However, a web based anti-phishing proxy brings up Using the most relevant terms found in a pages con-
other issues. Users are taught that one defense against tent, CANTINA [17] identifies phishing sites when their
phishing attacks is to always manually enter the URL or search engine ranking is not sufficiently high. This
to follow a bookmark. Using a proxy may train users to method identified phishing sites with a 97% true posi-
trust filtering their traffic through a third-party site. This tive rate. Garera [14] identified some common features
could compromise the user’s privacy. Attackers can eas- in phishing sites such as URL obfuscation techniques and
ily set up what they claim to be a phishing-filter proxy to page lifetime and ranking from a search engine perspec-
gather information about the user’s accounts or simply tive. Simply classifying sites based on 15 features, phish-
to phish. Users will need to be able to authenticate the ing sites were identified with an average accuracy of over
identity of the proxy. Another issue, unique to consumer 97%.
mobile devices, is the design problem of being unobtru-
sive yet informative on devices with limited screen real
estate.
7 Conclusions

6 Related Work We were able to identify several vulnerabilities on the

iPhone’s browser in its URL display, chrome, and in-
Previous studies investigated the causes for users put. From our user study, we observed that the major-
falling for phishing attacks. Dhamija [12] studied user ity of users without security backgrounds were unable
interface elements of web pages and browsers and iden- to detect phishing attacks, even those familiar with the
tified errors users made when misidentifing fraudulent iPhone. When presented with the scrollTo() page
websites. Users lacked understanding of the difference and a fake chrome that made the page scroll incorrectly,
between page content and browser program elements users proceeded because they thought it was an iPhone
(chrome). They did not understand or failed to noticed glitch.
the presence or absence of security indicators. We con- Porting the traditional browser to a mobile device with
structed similar spoofs of websites with changes to ele- limited computation power requires considerably more
ments such as the faked browser chrome and show the foresight because these devices cannot upgrade to new
increased susceptibility of users on limited browsers. versions as easily as desktops or laptops. The immedi-
Jakobsson [15] introduced “context aware” attacks where ate design priority for usability diminishes the focus on
phishing attacks took into account factors surrounding a security, but users are nevertheless being encouraged to
users access of a website. Customizing phishing sites do more of their important tasks from mobile devices, as
for new non-traditional browser platforms can take ad- evidenced by the creation of mobile sites by banking in-
vantage of increased user unfamiliarity to cause users to stitutions, online merchants, and social networking sites.
make security mistakes. To diminish the power of malicious denizens on the In-
Anti-phishing tools try aid users in discriminating le- ternet, we proposed a browser and device independent
gitimate sites from phishing and are integrated into the proxy service that may help bridge the gap between mo-
browser to help stop phishing attacks. Spoofguard [11] bile and traditional browsers.
identifies potential phishing sites via a series of heuris-
tic tests examining the URL and page contents for traits
found in known phishing sites. It communicates a warn-
ing to the user with an extra icon toolbar. Similar toolbars 8 Acknowledgements
such as Spoofstick [8], Netcraft [7] Toolbar, and Trust-
bar [9] try to present similar warning cues to the user. We wish to thank the anonymous reviewers who pro-
However, Wu found that users fail to pay attention to vided us with valuable feedback.

7
References
[1] Amazon. http://www.amazon.com/phone/.
[2] Bank of America Mobile Banking. https://www.
bankofamerica.com/mobile/.
[3] Firefox Phishing Protection. http://
www.mozilla.com/en-US/firefox/
phishing-protection/.
[4] Internet Content Adaptation Protocol (ICAP). http://
www.rfc-editor.org/rfc/rfc3507.txt.
[5] iPhone User’s Guide. http://manuals.info.
apple.com/en/iPhone_User_Guide.pdf.
[6] Microsoft Phishing Filter. http://www.
microsoft.com/protect/products/
yourself/phishingfilter.mspx.
[7] Netcraft Anti-Phishing Toolbar. http://toolbar.
netcraft.com/.
[8] Spoofstick. http://www.spoofstick.com/.
[9] Trustbar. http://trustbar.mozdev.org/.
[10] W3Schools Browser Display Statistics. http:
//www.w3schools.com/browsers/browsers_
display.asp.
[11] C HOU , N., L EDESMA , R., T ERAGUCHI , Y., B ONEH ,
D., AND M ITCHELL , J. C. Client-side defense against
web-based identity theft. In NDSS ’04: Proceedings of
the 11th Annual Network and Distributed System Security
Symposium (February 2004).
[12] D HAMIJA , R., T YGAR , J. D., AND H EARST, M. Why
phishing works. In CHI ’06: Proceedings of the SIGCHI
conference on Human Factors in computing systems
(New York, NY, USA, 2006), ACM Press, pp. 581–590.
[13] E GELMAN , S., C RANOR , L. F., AND H ONG , J. You’ve
been warned: An empirical study of the effectiveness of
web browser phishing warnings. In CHI ’08: Proceedings
of the SIGCHI conference on Human Factors in comput-
ing systems (New York, NY, USA, 2008), ACM Press.
[14] G ARERA , S., P ROVOS , N., C HEW, M., AND RUBIN ,
A. D. A framework for detection and measurement of
phishing attacks. In WORM ’07: Proceedings of the 2007
ACM workshop on Recurring malcode (New York, NY,
USA, 2007), ACM, pp. 1–8.
[15] JAKOBSSON , M. Modeling and preventing phishing at-
tacks. In Financial Cryptography (2005), p. 89.
[16] W U , M., M ILLER , R. C., AND G ARFINKEL , S. L. Do
security toolbars actually prevent phishing attacks? In
CHI ’06: Proceedings of the SIGCHI conference on Hu-
man Factors in computing systems (New York, NY, USA,
2006), ACM Press, pp. 601–610.
[17] Z HANG , Y., H ONG , J. I., AND C RANOR , L. F. Cantina:
a content-based approach to detecting phishing web sites.
In WWW ’07: Proceedings of the 16th international con-
ference on World Wide Web (New York, NY, USA, 2007),
ACM, pp. 639–648.