Chapter 6: Internet Explorer 7 Defenses


Overview

When it comes to “living life on the edge,” nothing comes close to the threats posed through Web browsers. Step back and think about it for a moment. A Web browser interprets a reasonable complex language, HTML, and renders the results. But a Web page can also contain code in the form of scripting languages such as JavaScript, or richer more capable code such as ActiveX controls, Flash, Java applets, or managed code applications. Ignore for a moment the fact that mixing code and data is just bad for security. All this code and data make for an extremely rich and productive enduser story, but it’s hard to secure. But we’re not done yet. The Web browser can render multimedia objects such as sound, JPEG, BMP, GIF, and PNG files. Perhaps the GIF files are animated. Many file formats are handed off to helper objects, called MIME handlers. Examples include video formats rendered by Quicktime, Windows Media Player, or RealPlayer. This all sounds like a lot of functionality to expose to the Internet. But we’re still not done. Next, the Web user can browse any Web site on the planet, and the server at the other end could be hosting Web pages designed to attack the user. A malicious Web page could take advantage of many possible attack vectors; some vectors are under the direct control of the browser and some are not.

In some cases, malware can install on a computer without the user realizing, often referred to as a “Drive-by Download.” Such downloads can install malicious code on the computer or upload sensitive data to an attacker. In most cases, the best a browser can do when faced with a possible download is ask the user to download or not, depending on the browser settings.

Drive-by downloads often work because the user is an administrator; if the user is a standard user, then malware would find it much harder to manipulate the operating system.

All this makes for an extremely hostile threat environment. Put simply, browsers are wonderful conduits for attacking users.

One remedy is to simply remove all the mobile code, such as script, Java applets, and so on. There is one ever-so-small problem with this solution: It’s a nonstarter. Imagine if all this code was removed: your online bank would not work; it’d be much harder to make an online hotel reservation or make an online purchase. Users have learned to expect a certain level of functionality, and taking that away would incite riots.

At Microsoft, we recognize that browsers will have security bugs, and attackers want to exploit them. Hand-to-hand combat with individual browser security bugs is a losing proposition. For Windows Vista, then, we decided to continue, and substantially enhance, the Internet Explorer defensive work started in Windows XP SP2. Some of these defenses and changes can be used by developers building on top of Internet Explorer 7, and others pervade the browser and have an impact on the way developers build software and how code runs within the browser.

Important  

In the previous paragraph we used the words, “browsers will have security bugs.” But the problem extends beyond bugs in browsers; if you create any form of browser extensibility, then your code can be attacked also using the same conduit of attack: the Web.

This chapter is divided in two large sections. The first explains the major Internet Explorer defenses and how they affect developers. The second portion explains the security features in Internet Explorer that developers can take full advantage of.

Finally, a third, smaller section that covers some Internet Explorer 7 changes that may pose issues with your application.



Writing Secure Code for Windows Vista
Writing Secure Code for Windows Vista (Best Practices (Microsoft))
ISBN: 0735623937
EAN: 2147483647
Year: 2004
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net