SafeHTML: Friend or Foe?

Executive Summary: Microsoft introduced SafeHTML in its article "Incorrect Attachment Processing in Exchange Server 5.5 Outlook Web Access Can Run Script" in June 2001. However, Exchange 2003 was the first Exchange version to include SafeHTML in its base code. Both Exchange 2000 and Exchange 5.5 required a hotfix to activate the capability. The feature is present in Exchange 2007 and 2003 and can't be disabled. Is it an advantage or a disadvantage?

The purpose of Outlook Web Access's (OWA's) SafeHTML feature is clear: to make viewing HTML documents safe. But the safety concern arises because the code that drives OWA is essentially a script—a very complicated script, but a script nonetheless. For OWA to function, the security zone in which it runs must be script-enabled (by accessing Tools, Internet Options, Security from within Microsoft Internet Explorer—IE; other browsers have other mechanisms for enabling and disabling scripting). The security zone a script executes within defines what local resources it can access. For example, a script running in a high security zone could potentially modify local files. A script running in a low security zone could not. Thus, low security zones provide enhanced protection for your computer, but they also have fewer capabilities because of that.

Why is that a problem? OWA won't execute code within the main message that it deems malicious. However, because of the way IE protects your local computer, attachments aren't subject to the same type of protection. OWA has to be extremely careful about which attachments it lets you view, so when OWA opens an attachment in an IE child window (or tab), and a malicious script is present in that attachment—or that script could conceivably perform malicious acts against the user's mailbox (or any mailbox to which the user has privileges) —OWA must take action to protect the contents of the mailbox. It can't allow the destruction or unwarranted access of data.

Enter SafeHTML, which examines the attachment before the system sends it off for display in another window. If SafeHTML sees content that might be harmful, it strips that content—and, unfortunately, if it isn't certain about the script’s intent, it just strips the entire attachment. Problems arose with early versions of SafeHTML, which weren't terribly intelligent. If an attachment contained a script block or appeared to have certain keywords that were indicative of various scripting languages (e.g., JavaScript, VBScript), SafeHTML stripped the entire attachment. Despite that, SafeHTML sounded like a good idea at the time. But then, we learned about what SafeHTML does when it sees an HTML form POST in a non-HTML document: It strips the entire document , too. You can see how SafeHTML might get in the way of users just “trying to get the job done.”

3 Levels of Classification
OWA classifies documents into three categories, based on the MIME type of a given file. The categories are Level 1 (block the file completely, allow no operations from within OWA), Level 2 (allow save-to-disk operations, but don't allow viewing in OWA), and Level 3 (scan the file and try to display it)—and Level 3 describes SafeHTML. Another option is available: In OWA 2003, you can prohibit attachment processing completely (on a per-back-end-server basis); OWA 2007 adds the capability of doing so globally for the entire Exchange organization.

You can adjust the MIME types and file extensions included in Level 1 and Level 2 on each front-end (Exchange 2003)/client-access (Exchange 2007) server by modifying the registry on that server. With Exchange 2007, you don't have to adjust the registry directly; you can modify the Direct File Access properties for the OWA web site on each server’s property sheet in the Exchange Management Console. You can't adjust Level 3 MIME types and file extensions. Generally speaking, the defaults work just fine.

The sending server specifies MIME types for each attachment; the message recipient doesn't specify them in any way. Therefore, it's possible that a user might receive an executable file that endswith—for example—a .txt extension. (In fact, this is a common way to send executables between email systems.) It's also possible to receive an HTML document in a file that has no extension. And a VBScript or a JavaScript program can be sent (as a program) with a .txt file extension. This potentially dangerous scenario is one of the security problems that SafeHTML attempts to address.

Note that a change in Exchange 2007 SP1 affects SafeHTML. For example, if you have an XML document that doesn't end with the .xml file extension, SafeHTML will strip the content.

My SafeHTML Encounter
I first encountered SafeHTML while helping a Fortune 500 company migrate to Exchange. Office workers were using Microsoft Office Excel's send-via-e-mail feature to send email through their old email system to recipients whose mailboxes were already migrated to new Exchange servers. In my test environment, this setup worked fine because the test environment used the final configuration—that is, all the desktops had Outlook installed. But the group of migrated Exchange workers was using OWA as an interim solution because we wanted to roll out Outlook to all desktops simultaneously. The old desktop email client provided the attachment with an .xls extension, as you would expect, but the old email system applied an incorrect MIME type to the attachment. Because the MIME type wasn't in either the Level 1 or Level 2 lists, OWA stripped the entire file because SafeHTML deemed its content dangerous.

Scanning the definitions of Levels 1, 2, and 3 left me with no good answers. Modifying OWA for the client wasn't feasible either. Part of the project charter was to install commercial, off-the-shelf (COTS) software with no modifications; modifications to the old email system were what made the migration difficult in the first place. As an aside, modifying OWA may not have been feasible anyway. Much of OWA's capability is tied up in libraries that can't be modified.

I had two choices: I could either install the Outlook client prematurely (and thus increase support overhead and personnel requirements) or have the office personnel save the attachment to disk and open the file with Excel. For budgetary reasons, we tried the save-to-disk option first, but immediately that option became politically impossible. Too many administrative personnel complained about the additional overhead the process introduced into their operations. So, I backtracked: I installed the Outlook client on users’ desktops and adjusted the product plan accordingly.

Be Wary
You can learn a couple things from my story. First, test any process that affects all phases of your project plan. Second, even the best-laid plans can go awry. Finally, even features that you might not know exist can surprise you! SafeHTML, designed to protect users from malicious software (seemingly a very friendly thing to do), can have unexpected effects. Rather than helping users, it can sometimes prevent users from getting their work done. You’ll have to decide for your applications whether SafeHTML is a friend or a foe.