authentication with a hardware token and use of various click-based keyboards to avoid key loggers. In some cases banks may ask the user to authenticate each transaction with a hardware token. Although some of these techniques definitely improve security, they can place a heavy burden on the end user.
Another usability feature of the Web browser that malware has attacked is the auto-complete function. Auto-complete saves the form information in a safe location and presents the user with options for what was typed before into a similar form. Several families of malware, such as the Goldun/Trojan Hearse, used this technique very effectively. The malware cracked the encrypted auto-complete data from the browser and sent it back to the central server location without even having to wait for the user to log in to the site.
Given all the vulnerabilities out there and the willingness of attackers to exploit them, you might think that users would be clamoring for more security from their browsers. And some of them do—as long as it doesn’t prevent any of their desired features from working.
Let’s start with the browser software itself. From a security engineering perspective, the obvious choice for browser software (or any software) is to ship it in a locked-down state, with all security features turned on. Then the user or enterprise may choose to weaken the security by enabling functions that they want. Consumer software that has done this has generally failed in the marketplace. Consumers want security, but they don’t want to think about it or configure it. If the shipped configuration does what they want, they probably will not alter the configuration much, if at all.
Therefore, the browser designer faces the Goldilocks problem. Either the porridge is too cold (not usable because of the demands of the security lockdown) or too hot (too easy to abuse because not enough security measures are in place, or are too weak). Designing a configuration that is “just right” is nearly impossible because
of evolving threats, uncovered bugs, and differing user tolerances for frustration.
There are any number of documents available that list steps one can take to lock down a Web browser. For example, one of those steps is often something like “ Disable JavaScript.” Few people actually ever do that, however—at least not permanently—because using a browser with JavaScript turned off is annoying, and in many cases prevents you from visiting sites you have legitimate reasons to visit.
Cookies, while sometimes flushed to solve a problem, are essential to many Web sites, and having them disabled will prevent a wide range of services from working.
Browser developers have been working overtime to address some of these issues—and with some success—but it is definitely an uphill battle.
Proactive and reactive developers can generate an endless series of software updates. As a responsible defender, your dilemma is that allowing these updates in to your users without testing may break applications or even introduce security holes, but not allowing them may leave your enterprise open to even more serious attacks.
Distributed management provides some help in this area, but all major browsers are weaker than many defenders would like them to be. Microsoft provides the free Internet Explorer Administration Kit, which sets the bar for enterprise browser deployment and management tools, but that bar is lower than many would care for. FirefoxADM, an open source project for managing collections of Firefox browsers, is far more limited but a step in the right direction. FrontMotion provides a Web-based tool that allows a defender to create packages with approved software, configuration, and plug-ins for Firefox. All are available for Windows platforms only.
Firefox and Google’s Chrome browser have implemented sandboxes, in which the browser runs code (such as JavaScript or Flash) in a compartmentalized area of the program that provides only limited resources for the program and whose design is heavily scrutinized for security flaws. Internet Explorer uses a zone-based security model, in which security features are enabled or disabled depending on the site being accessed. Under Vista, Internet Explorer runs in what is known as Protected Mode, which limits the operating-system privileges the browser program can exercise.
References:
Archives