Microsoft Outlook Web Access (OWA) is a useful tool for giving remote or mobile users access to their Outlook mailboxes. Although OWA lacks some of Outlook's features, the overall user experience is similar to that of Outlook and is a reasonable alternative. However, some of the functionality that makes OWA useful and convenient also raises some security concerns—among them fears about attachment safety, either from sensitive information getting into the wrong hands or from malicious content that can harm a user's PC or the network. But rather than deny users the ability to use OWA to remotely access their mailboxes, you can take some steps to help secure OWA attachments and reduce the security risks involved. You can also plan ahead to take advantage of some new attachment-control features that Microsoft has included in Exchange Server 2007.

OWA Attachment Handling
When an OWA user receives an email message containing an attachment, the user can perform one of three actions:

• From within the browser, the user can right-click and save the attachment. This behavior is purely a function of the browser and has nothing to do with OWA.
• From within the browser, the user clicks the attachment link, and the browser displays a dialog box that asks whether the user wants to save or open the file. If he or she chooses to save it, the browser saves the file—again without OWA being involved.
• The user chooses to open the document, in which case, OWA sends an HTTP header to the browser indicating that the document expired the previous day. This causes the browser to not cache the document, although it might write the document to a temporary file area on the hard disk.

Note that in the first two cases, OWA has no control over what happens to the file. If the user chooses to save the file, the browser will simply ignore the "don't cache this" header. Even if you manually add the Cache-control: no-cache header to the Exchange virtual directory, users will still be able to save attachments. To amend this behavior, you can take advantage of OWA 2003's attachment-control features to prevent users from being able to open the attachments. To be specific, with OWA you can

• customize the list of file types that are completely blocked and those that can be opened only after saving to disk. This capability parallels the controls you get in Outlook when you install the Outlook Security Features Administrator Package.
• control whether users can access documents saved directly in public folders.
• restrict which servers users can use to access attachments.

These controls help prevent users from opening malicious attachments, and they give you a degree of control over where users can open attachments that might contain sensitive or proprietary data.

Blocking Attachments Depending on File Type
The first line of attachment control is restricting the types of files that users can open directly from the email message. This capability came about because Outlook users have shown a distressing tendency to open malware programs disguised as legitimate attachments. By making some file types unavailable in Outlook and requiring users to save other files to disk before opening them, the Outlook development team successfully blocked several potential attack vectors. OWA implements these same controls.

Attachment types that are completely unavailable are known as Level 1 file types; attachment types that users can save to disk but not directly open are called Level 2 file types. You can use a registry setting to control which file types are in each category. By adding the Level1FileTypes and Level2FileTypes values (of type REG_SZ) under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA registry subkey and setting the value of each to a comma-delimited list of the attachment types you want in that category, you can force OWA to block certain file types or force users to save them to disk first. For example, if you want to specify Perl (.pl) scripts as a Level 2 file type, perform these steps:

1. Log on to your OWA server with an account that has Windows administrative privileges.
2. Open a registry editor (regedit.exe).
3. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\MSExchangeWeb\OWA.
4. Double-click the Level2FileTypes entry.
5. When the Edit String dialog box ap- pears, scroll to the end of the string and add, "pl" (without the quotes). Click OK.

You can also customize the Level1MIMETypes and Level2MIMETypes, which instruct the OWA server to block attachments according to the MIME type of the file delivered by the server. This feature is useful if your users frequently work with messages that contain links to content that doesn't contain extensions (e.g., Macintosh-format files on a Windows file server) because you can block the MIME type that corresponds to the file content no matter what the actual file extension might be. It also helps protect you against situations in which the extension of an attachment doesn't match the true MIME type; malware payloads sent via email often contain misleading extension information that attempts to fool users and antivirus software. To customize the MIME types used for filtering, use the steps outlined for customizing the Level2FileTypes value, except you'll modify the appropriate Level1MIMETypes and Level2MIMETypes values.

Controlling FreeDoc Access
Public folders can contain many different data types. After Exchange 2000 Server shipped, the fact that public folders supported direct access via WWW Distributed Authoring and Versioning (WebDAV) led many organizations to store documents directly in public folders—not as attachments to posts in those folders, but as raw documents. Microsoft calls these documents FreeDocs, and they raise a security problem. FreeDocs can have embedded macro code that will execute in the local security context of the browser when someone opens the document. Exchange Server 2003 blocks FreeDoc access from OWA out of the box. You can override this behavior by adding a new REG_DWORD value named EnableFreeDocs under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA, then customizing its value. You can set the value to

• 0 to block all FreeDoc access from within OWA (OWA's default behavior). However, this setting doesn't stop Microsoft Office users (or others using WebDAV–capable applications) from creating and opening FreeDocs.
• 1 to block FreeDoc access from front-end servers but allow access via WebDAV and via back-end servers.
• 2 to allow FreeDoc access from back-end servers and from front-end servers whose names appear in the AcceptedAttachmentFront Ends value. You specify the set of allowable front-end servers by creating or adding to a comma-delimited list that includes the Fully Qualified Domain Name (FQDN) of each server. The list should go in a REG_SZ value named HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\AcceptedAttachmentFrontEnds.

To set the way OWA handles Free-Docs, perform these steps:

1. Log on to your OWA server with an account that has Windows administrative privileges.
2. Open a registry editor (regedit.exe).
3. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\MSExchangeWeb\OWA.
4. Right-click HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\MSExchangeWeb\OWA and select New, DWORD Value. Name the new value EnableFreeDocs.
5. Double-click the new value, and in the Edit DWORD Value dialog box, enter the desired value.
6. Click OK.

Controlling Access to Attachments Via Front-End Servers
Blocking certain types of attachments or documents is useful in itself, but sometimes you want to keep people from accessing attachments depending on where the person is, not just what the file type is. This concern is due to the nature of how OWA works. Outlook is typically installed on a machine in an environment in which the user is presumed to be an honest member of the company, and therefore it's reasonable to assume that the machine is under the user's control and is in a place where it's safe for the user to open sensitive attachments. OWA, however, is designed to be used from most any modern Web browser—even browsers running on machines that aren't under the user's control and aren't necessarily safe. OWA 2003 addresses this problem in a couple of ways, such as its provision for automatically ending users' sessions after an administrator-specified time period. (You can set separate times for public and trusted computers.) OWA 2003 also lets you restrict which servers users can use to access attachments to help reduce the risk that users will open sensitive attachments on untrusted machines. For example, you probably wouldn't block Microsoft Word documents for all users, but you might want to prevent OWA users from accessing Word documents from outside the corporate network. OWA 2003 offers two interlocking controls that let you do this fairly easily.

First, the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\DisableAttachments subkey lets you control whether attachments are open, blocked, or open only for users who are connecting directly to a back-end server. When you create this entry, you can assign one of three values:

• A value of 0 tells OWA to allow unrestricted attachment access. This is OWA's default behavior.
• A value of 1 forces OWA to block access to all attachments. This is pretty draconian and probably not appropriate for most environments.
• A value of 2 allows attachment access for users who connect directly to the back-end mailbox server. If you're using a front-end/ back-end topology, this effectively restricts attachment access to users inside your firewall (or those that can establish sessions directly to their mailbox servers).

To apply this setting, perform these steps:

1. Log on to your OWA server with an account that has Windows administrative privileges.
2. Open a registry editor (regedit.exe).
3. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\MSExchangeWeb\OWA.
4. Right-click HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\MSExchangeWeb\OWA and select New, DWORD Value. Name the new value DisableAttachments.
5. Double-click the new value, and in the Edit DWORD Value dialog box, enter the desired value (e.g., use a value of 2 to block outside attachment access).
6. Click OK.
7. Stop and restart the World Wide Web Publishing service. (You can quickly do this from the command line by using the net stop w3svc and net start w3svc commands.)

Additionally, you can use the Accepted AttachmentFrontEnds value (of type REG_SZ) under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA subkey to allow users who connect to specified front-end servers to access attachments. Any request that comes from a server whose host header matches the name of a server on the AcceptedAttachmentFrontEnds list will be accepted. (Use commas to separate the entries on the accepted server list.) This setting takes effect only if the DisableAttachments value is set to 2.

Note that the Level 1 and Level 2 block lists take precedence over DisableAttachments. If you specify that a particular file type should be blocked, it will be blocked for all users, no matter what DisableAttachments is set to.

OWA 2007 Attachment-Control Features
Microsoft has added two significant new attachment-control features in the Exchange 2007 version of OWA. The first, OWA Document Access, allows the OWA server to translate links to internal Windows SharePoint Services Web sites for use by Internet clients. This gives OWA users read- only access to administrator-specified SharePoint sites—provided the users have access with their normal Windows accounts; Document Access uses the user's credentials to request access. This SharePoint functionality reduces the need to send attachments via email in the first place.

The second feature, WebReady Document Viewing, is an HTML transcoder that renders some Office document types (e.g., Word, PowerPoint, Excel) and PDF files as HTML pages. This feature prevents users from modifying an attachment's content, and it means that there's no longer an easy way for users to save an intact document file to an untrusted machine. Look for more coverage of both of these features in future issues.

Technical Solutions to Behavioral Problems
Controlling access to attachments is part of a strong security posture, and OWA offers some security features that can help reduce the risk that a user will accidentally leave copies of sensitive attachments on untrusted machines or that an attachment containing malicious content will cause damage to your network. However, these features aren't foolproof. For example, a sufficiently determined user can simply rename a file before sending it to evade the file-type blocking restrictions.

If your email users frequently exchange or send sensitive documents, you need to couple the technical measures discussed here with user education that helps them understand what the security measures are for and why they're implemented. Then you need to design a security policy that specifies proper attachment-handling procedures. OWA's attachment-management features will help make that policy a reality.