Gunter Ollmann, director of security strategy with IBM Internet Security Systems, wrote a short paper on designing applications to be resistant to infected hosts. Ollmann offers some solid, high-level design advice that Web developers should read and consider adopting. But the paper also highlights the difficulty and complexity in securing the Web-based ecosystem.A man-in-the-browser attack is similar to a man-in-the-middle attack, except the man-in-the-browser inserts itself into the browser process, letting the attacker manipulate the Web interactions between a user and a server. For example, an attacker could interrupt the application flow and insert fields that ask for sensitive information.

Ollmann's paper describes the attack and some of the potential results. What is more important are his suggestions for mitigating some of the attack vectors in the application design phase rather than lobbing more technology on the client. Client software is simply inadequate to deal with quickly evolving threats, whereas addressing weaknesses in the application code -- something the developer can control -- makes more sense.

For all the security technology available to corporate and consumer users to protect their computers and information from malicious users, the best protection always comes down to good application design and engineering. Some of his advice -- potentially the most interesting advice -- treats failures as failures with the potential of disrupting the user experience, and that is something companies won't do. Four years ago, maybe more, I was saying that Web sites like financial and health institutions must stop sending e-mails with links in them because phishing was so prevalent and determining a legitimate e-mail from a phishing e-mail is so difficult. Of course, making users type in a URL is less "friendly" than clicking a link and convenience is much more important than taking simple steps to protect customers from sophisticated attacks. Companies that should know better are still sending out e-mails with links. Ridiculous.

Not all of Ollmann's suggestions are going to be easy. Ollmann suggests examining application flow and then telling users how many steps there are, or presenting information to users in ways that would be difficult for an attacker to manipulate. Application and user interface design already is complicated. Trying to communicate to nontechnical users what they should see at each step in an application is a tough nut to crack, an issue that Ollmann readily acknowledges. How do you tell users who know nothing of Web applications what to expect in a succinct manner?

Ollmann suggests presenting visual materials like screenshots or PDFs to users or using graphics and page layout techniques to inform the user of authentic versus unauthentic page elements. The suggestions may help, providing users actually read the visual materials and understand their meaning. Obviously, there are other ways to inform users. Ollmann's point is that doing so is advantageous.

Of course, one of the potentially more controversial suggestions is using page layout elements, HTML or CSS, that will only render properly if they are not manipulated by something between the client and the server. For example, using a background image that will only appear whole based on a fixed container size. The problem is that since browsers tend to render HTML and CSS differently, coding for browsers is time-consuming, expensive, and error-prone.

Internet Explorer is most widely used, followed by Firefox, Opera, and others, but even in each of those families, different versions render HTML and CSS differently. Add in browser extensions and who knows what you get? Organizations are forced to make users use a specific browser and version, which may alienate some potential customers, or continue to let users interact with potentially insecure browsers.

There are no easy answers here. Designing Web applications is difficult and there are many points to consider, like user experience and efficiency. But organization's applications that manipulate private or sensitive data must be designed to protect users from their own actions as well as malicious attacks. Anything less is irresponsible.