Security zone shortcomings: why browsers and websites encourage phishing

Hello everyone. Since this is my first blog post, an introduction is warranted. My name is Jeff Forristal, and I'm a recent addition to the SPI Labs team at SPI Dynamics. I came to SPI from a security services company, and have almost a decade of security experience--particularly in the web arena. In the past I've written multiple magazine articles and contributed to a book on various security-related topics. I have a very practical security outlook: I want to see real security solutions that can be used and succeed today, because that's what is needed. Theories are fine, but until they are implemented and deployed, they don't make the world a safer place.

Which brings me to the topic of browser security zones, which are particularly notable in Internet Explorer and are a part of Microsoft's general remediation strategy for many of the vulnerabilities found in IE. For those of you unaware or unfamiliar with browser security zones, the short story is that web sites can be classified into 'zones'. There's typically a zone for web sites you explicitly trust (such as your bank), a zone for local/intranet web sites (typical in a work environment), and then an Internet zone for everything else. The goal is to reduce the security privileges given to the Internet zone (i.e. restrict what the Internet at large can do to/with your browser), while having more relaxed restrictions for sites you trust (letting them perform more security-sensitive operations). In a perfect world, you would configure your browser to disable Javascript, ActiveX, Flash, and all other excessive features in the Internet zone. This would reasonably protect your browser against any Javascript-based attack (including attacks related to phishing and XSS) and likely curb direct browser exploitation by a native browser vulnerability.

Great...in theory. However, I've spent the last four+ years living this approach and it has proven to be borderline unusable at times, and down-right frustrating most other times. But I'm not going to place all the blame on the web browsers themselves--web sites boast architectural design decisions and page implementations that do not cater to zoned browsing (and in some cases, make it nearly impossible to configure the site to be trusted at all!). Not to mention, any Web 2.0/AJAX style application requires full trust due to the amount of client-side technology it needs to leverage.

As I've said, I've lived with the security zone browsing model in IE for the last four+ years. As a security practitioner, I felt it necessary to 'practice what I preached', especially since I often told enterprise clients that they should consider leveraging security zone policies in corporate environments to reduce the potential for client-side exploitation and the introduction of browser-sourced malware into their internal network. Well, after using the security zone model for the first year (i.e. disabling Javascript, amongst other things, for the Internet non-trusted zone), I stopped making that recommendation. Trying to not trust the Internet at large and explicitly trust certain sites proved too cumbersome and often impacted my browsing experience (or prevented it entirely). Many folks often incite the 'Grandmother usability rule' (i.e. "It needs to be so easy that my computer-illiterate grandmother must be able to figure it out"); the use of security zones definitely falls short in that regard. And if I, a web and security expert, can't make browser security zones work as a practical reality, then I don't want to think about the effectiveness it will (or more appropriately, won't) have with the rest of the world at large. [As a side note, I still to this day use restricted browser zones, as painful as they are; they are a necessary evil given all the vulnerabilities in browsers and IE in particular.]

Common issues encountered on websites running in non-trusted zone

Over a decade ago I was the webmaster for a web design company based in Chicago. I developed a mantra back then, and I've stuck to it through today: a good website design should not depend on Javascript and/or should gracefully degrade when Javascript is disabled. Now, AJAX aside, this is a good mantra to live by--especially if you're a security practitioner (check out http://ha.ckers.org/ for all the evil/fun things people are doing with Javascript these days). The requirement of Javascript essentially forces the user to trust your web site (or the Internet at large) in order to achieve full functionality...and that's essentially a strongarm tactic that erodes the value of browser security zones. Now, I can see the requirement of Javascript for unique or complex calculations or functionality (Google maps, anyone?)...but so many sites use it in obnoxious ways:

* They use a Javascript-based URL redirect instead of the functionally equivalent meta refresh HTML tag (particularly when there's no URL parameters that must be calculated/passed)
* They use a Javascript onclick() URL location changer in an HTML anchor tag while leaving the href attribute empty (causing the browser to go nowhere if the link is clicked and Javascript is disabled)
* They have users enter their credentials/data into a visible form, and upon submission, use Javascript to copy the credentials/data to a hidden form and submit the hidden form instead (many cite client-side validation as the reason, but proper security requires you to do server-side validation anyways)
* They use dynamic Javascript or Flash menus and provide no other 'normal link' method to navigate their site
* They use Javascript to load/define CSS elements, or otherwise render basic aspects of the page (look at http://www.hp.com/ without Javascript to see what I mean)

While all of the above issues are Javascript-related, a bigger and more devious web site issue that breaks zone-based browsing involves the use of multiple domain names particularly for form submissions, redirects, and frames. The current security zone model is dependant on domain names; domain names are used to classify the sites into the appropriate zone. You can use wildcards (at least with IE) to help save data entry for sub-domain names; i.e. you can enter *.bankofamerica.com and it will trust all the sub-domains of the bank (cgi.bankofamerica.com, images.bankofamerica.com, etc.). The wildcard method is a real time saver--that is, if web sites were smart enough to stick with sub-domain names rather than entirely different domain names. Instead, some web sites redirect to or utilize form processing at a third-party site, or the target site may be hosted on an affiliate domain. That breaks the zone-based model because the trusted transaction will become interrupted and be demoted to an untrusted level somewhere in the middle of the transaction, typically causing errors. To make matters worse, it's often unclear to a user where/how/why the process broke, and the user is left no information that tells them anything about the use of the untrusted domain name. Thus the user has to view the HTML source and figure out what domain names need to be added, and hopefully be able to retry/restart the transaction/process after the untrusted domain names are configured to be trusted.

Experian is a good example of this point. After browsing their main web site (http://www.experian.com/), clicking various 'Get my credit report' links will take you to experiandirect.com or creditexpert.com--both Experian sites but different than the main domain name of experian.com. eBay is another site that I had issues with (albeit it was over a year ago and I haven't tried it since). The 'Sell Your Item' process involved requests to a half-dozen eBay hosts which didn't use the .ebay.com root domain (for example, they used 'ebay-imgs.com' for picture hosting, and that didn't match the wildcard *.ebay.com...why they couldn't have used imgs.ebay.com I'll never know). Needless to say I was never able to discover and add all the appropriate domain names into the trusted zones list in order to get eBay's seller wizard to function correctly.

Shortcomings in the browsers

IE doesn't win any awards for making the secure zone browsing easy and manageable. Normally IE will display the zone(s) that are currently used in the lower left corner, making it somewhat easy to see if you are in a trusted or Internet zone (see previous graphic above, left). Things start to break down when multiple zones are in use at once, leading to a 'Unknown Zone (Mixed)' label. Unfortunately IE provides no way to figure out what domains (particularly the untrusted ones) exist that trigger the mixed zone classification--and double-clicking on the mixed zone message (the only operation it supports) merely calls up the security zone configuration dialog. Kudos for IE for making the configuration dialog directly accessible, but we still don't know what to adjust (i.e. what domains to add to the trusted list). So IE gives some indication of the problem, but hides the necessary details from the user in order to correct it. The graphic below shows what happens in IE.
What happens when you double-click the zone message in IE

Recommendations for websites

If you're designing/implementing a web site, there are a lot of things you should do to ensure you are not encouraging bad security habits from your users. The evident recommendations from the previously-identified issues:

* Aggregate everything under one domain name, so a single wildcard will cover all hosts necessary to utilize your web site; adjust agreements with third parties to use "thirdparty.yourdomain.com" instead of "yourname.thirdparty.com" URLs
* If a form/process utilizes offsite processing, you should alert the user before they start the process, and list the exact domains that will be encountered so they can be configured into the trusted zone correctly; screenshot examples of how to get to the security zone configuration dialog, and a list of what to add, would be ideal
* All anchor tags should have an href; you can still have onclick() handlers, but at least degrade gracefully and have a normal link to the most appropriate location if Javascript is disabled
* Use meta refresh tags, if possible, when you need page-level redirection
* Separate your CSS and Javascript; make sure CSS is still available even when Javascript is disabled
* If you're using dynamic Javascript menus or Flash menus, be sure to gracefully degrade to a normal HTML menu, and/or provide a text menu version at the bottom of the page; this has always been an issue for accessibility reasons, and recent legal movements may have ADA requirements reaching online web sites too
* Above all else, if your page must absolutely require Javascript, then alert the user to this fact and guide them to how to add the site to the trusted zone (rather than how to enable Javascript in the Internet zone...that would be bad); also, include a link to continue what they were doing/where they were going on that same alert page so they can continue where they left off after they enable Javascript

Possible changes in web browsers

This is going to be less actionable list of suggestions, since it's doubtful that browser vendors will wander across this list and actually implement them. But for thoroughness's sake, I thought I'd throw them out there.

First, provide a usable guide to easily add the necessary domains/configuration when the site is in the untrusted/Internet zone. In IE, for example, the best you get right now is double-clicking on the zone status message (Internet, Trusted, or Unknown/Mixed) to pull up the zone configuration dialog. At least IE 7, compared to it's older kin, auto-populates the site's domain name into the site URL box when you open up the trusted sites list...that's a nice step. But what would be even nicer would be a popup list of the domains for a given page, the associated zone, and the ability to immediately add the zone to the trusted list. So when there is an Unknown/Mixed zone message, clicking on it should give the user enough info and choices to immediately remedy the problem (by adding the missing domain name to the trusted zone list). A mock-up of what I mean is displayed below (it assumes the user was browsing at www.site.com and got a mixed zone result). Whether the dialog is a tooltip-type popup or a separate floating dialog doesn't matter--all that matters is that it should be accessible via the zone status message on the browser status bar.
Better zone management popup menu

The second possible change is a bit far-fetched and has to do with combating phishing attacks specifically. A common phishing attack is to harvest the usernames and passwords of a given site; an attack typically poses a fake login form of some well-known web site (MySpace, eBay, Bank Of America, etc.) that is convincing enough to users to trick them into entering their credentials. The fact that such attacks are currently succeeding means people aren't using browser security zones, or are ignoring them, since the facade login forms will definitely not trigger Trusted zone status (and the corresponding status message in the browser's status bar). So what's needed is a way to prevent such logins when they aren't in the correct trusted zone--and that's the solution.

User logins typically involve a username and a password/PIN. In HTML, the password/PIN uses a password input type; this causes some dots/asterisks to appear as a user types in their password, rather than the actual password. The concept of hiding a typed password is not new--it's used to prevent shoulder surfing (looking at someone's password over their shoulder as they type it). Now, if something is important enough to warrant the use of a password input box, then it's a feasible assumption to say that it must be security-sensitive to some degree, and because of that, it should only be given to trusted web sites. And if that password input box is not being sent to a trusted site, well, then something fishy is going on...after all, why would the user want to send a security-sensitive password to a site they don't trust? Thus the recommended browser change: warn/stop a user from submitting a form which contains a password input type if the form action is submitted to a non-trusted site. Require the user to explicitly trust the site that receives the password (by having the site's domain listed in the Trusted sites list). If the site is not already trusted , then pop up enough warning dialogs to get them to understand that they are sending their password to an untrusted site...which could help expose phishing attacks. Most browsers already implement this feature when an HTTPS submission redirects to a non-secure HTTP location--this would be nearly identical, except the browser alerts when data is going to a non-trusted web site rather than a non-secure (i.e. non-HTTPS) web site. Sure, users could still ignore this feature, or phishers could use regular input boxes instead of the password input boxes, but at least in both cases something will be drastically different and could serve to warn the user.

As great as security zones are, they are not the final solution. Since security zones are domain-based, there are problems when you only want to trust a small part of a much larger web site. This can be problematic for multi-user web systems, such as forums, blogs, etc. By trusting a host in order to access your blog, you are also trusting the content of everyone else's blog on the system. Thus you are not only trusting the system, but all users of the system as well; an attacker capable of compromising one user account and uploading malicious Javascript content will have the Javascript execute within a trusted zone (assuming you wander across that page).

In the end, there still is no perfect web browser security solution that is people-proof...which is why every little bit helps. So if web sites and browser vendors pitched in a little bit, we just might be a little better off in this ongoing cat-and-mouse dance between normal users and phishers/attackers.

Surf safely!