Add to this threats that are more social and less technical in nature—phishing, ⁴ for example. In phishing, victims might receive a perfectly reasonable e-mail from a company that they do business with containing a link to a Web site that appears to be legitimate as well. They log in, and the fake Web site snatches their username and password, which is then used for much less legitimate purposes than they would care for. A phishing scam depends much more on the gullibility of users than on the technology of the browser, but browsers often take much of the blame.

There are attacks of this nature based on the mistyping or misidentification of characters in a host name. A simple example of this would be that it is tricky to spot the difference between “ google.com” and “ googIe.com” (where the lowercase l has been replaced by an uppercase I) in the sans-serif font frequently used by browser URL entry fields. Expand that attack to Unicode and internationalization and you have something very painful and difficult to defend against.

Cookies are a long-used mechanism for storing information about a user or a session. They can be stolen, forged, poisoned, hijacked, or abused for denial-of-service attacks. ³ Despite that, they are an essential mechanism for many Web sites. Looking through the list of stored cookies on your browser can be very educational.

Similar to browser cookies are Flash cookies. A regular HTTP cookie has a maximum size of 4 KB and can usually be erased from a dialog box within the browser control panel. Flash cookies, or LSOs (local shared objects), are related to Adobe’s Flash Player. They can store up to 100 KB of data, have no expiration date, and normally cannot be deleted by the browser user, though some browser extensions are becoming available to assist with deleting them. Although Flash is run with a sandbox model, LSOs are stored on the user’s disk and may be used in conjunction with other attacks.

In addition to Flash cookies, the ActionScript language (how one writes a Flash application) supports XMLSockets. This gives Flash the ability to open network communication sessions. XMLSockets have some limitations in that they aren’t permitted to access ports lower than 1024 (where most system services reside) and they are allowed to connect only to the same subdomain where the originating Flash application resides. Consider, however, the case of a Flash game covertly run by an attacker. The attacker runs a high-numbered proxy on the same site, which can be accessed by XMLSockets from the victim’s machine and redirected anywhere, for any purpose, bypassing the limitations of XMLSockets. This trick has

already been used to unmask users who attempt to use anonymizing proxies to hide their identities.

Clickjacking is a relatively new attack, in which attackers present an apparently reasonable page, such as a Web game, but overlay it with a transparent page linked to another service (such as the e-commerce interface for a store at which the victim has an account). By carefully positioning the buttons of the game, attackers can cause their victims to perform actions from their store accounts without knowing that they have done so.

SECURI T Y VERSUS USABILI T Y

Usability and security have long been at odds with each other in software design. The browser is no exception to that rule.

When browsing the Web or downloading files, the user constantly needs to make choices about whether to trust a site or the content accessed from that site. Browser approaches to this have evolved over time—for example, browsers used to give a slight warning if you accessed a site with an invalid HTTPS certificate; now most browsers block sites with invalid certificates and make the user figure out how to unblock them. Similar approaches are taken with file downloads. Internet Explorer tends to ask the user several times before opening a downloaded file, especially if the file is not signed. Frequently prompting the user for actions that are legitimate often creates user fatigue, which makes the user careless in walking the tightrope between software with a “reasonable but not excessive” security posture and a package that is either too open for safety or too closed to be useful. Most browsers today have evolved from the “make the user make the choice” model to the “block and require explicit override action” model.

In some cases the security of the browser has had a major impact on Web-site design and usability. Browsers present a clear target for identity-theft malware, since a lot of personal information flows through the browser at one time or another. This type of malware uses various techniques to steal users’ credentials. One of these techniques is form grabbing—basically hooking the browser’s internal code for sending form data to capture login information before it is encrypted by the SSL (Secure Sockets Layer). Another technique is to log keyboard strokes to steal credentials when the user is typing information into a browser. These techniques have spawned various attempts by Web-site designers to provide more advanced authentication methods, such as multifactor