Security Notes for Microsoft Office Solution Developers

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

 

Microsoft Corporation
July 2002

Applies to:
     Microsoft Office XP

Summary: Read a series of security notes for Microsoft Office solution developers, including behaviors triggered by Security dialog box settings, registry modifications, Microsoft Windows API calls, and digital code signing. (4 printed pages)

Contents

Microsoft Office XP Security Settings Matrix
About Microsoft Outlook Security Settings
About Setting Microsoft Office XP Security in a Testing Environment
About Modifying the Microsoft Windows Registry
About Making Microsoft Windows Application Programming Interface (API) Function Calls
About Digital Code Signing
About Deployment of Managed COM Add-ins in Microsoft Office XP
About Strong Passwords
Automating the Visual Basic Editor

Microsoft Office XP Security Settings Matrix

The following table lists the available Microsoft® Office XP security settings, along with their corresponding behaviors, in the Security dialog box (Macros submenu, Tools menu).

Aa163990.odc_securitynotes_1(en-us,office.10).jpg

Note   The availability of, and options within, the Security dialog box varies depending on the specific Office application. Additionally, specific Office applications silently load signed add-ins and macros only from specific directories, along with registered COM add-ins and smart tags recognizers. For more information, see the Microsoft Office XP Macro Security White Paper.

About Microsoft Outlook Security Settings

The security model for Microsoft Outlook® 2002 differs from other Office XP applications. In Outlook 2002, in addition to the security settings in the Security dialog box, COM add-ins (regardless of whether they are signed) are subject to the restrictions on certain Outlook 2002 object model calls imposed by the Outlook 2002 Security Update. For an Office COM add-in to have unrestricted access to the Outlook 2002 object model, the COM add-in must also be added to the Trusted Code list of the Default Security Settings (Admin.oft) template. For more information on the Outlook 2002 Security Update and the Default Security Settings item in the Outlook Security Settings public folder, see:

About Setting Microsoft Office XP Security in a Testing Environment

To install and run an unsigned COM add-in or Microsoft Visual Basic® for Applications (VBA) macro, the security settings in the Security dialog box (Tools menu, Macro submenu, Security command) must be set to Medium, with the Trust all installed add-ins and templates check box cleared. It is strongly recommended that you do this only in a testing environment. After you are done testing, set the security level back to High.

**Caution   **By setting the security level to Medium, with the Trust all installed add-ins and templates check box cleared, users will have the choice to either enable or disable unsigned COM add-ins and VBA macros when they are prompted. If your security level is set to High, with the Trust all installed add-ins and templates check box cleared, all unsigned COM add-ins and VBA macros will be disabled automatically. Therefore, it is strongly recommended that all users keep their security levels set to High with the Trust all installed add-ins and templates check box cleared.

About Modifying the Microsoft Windows Registry

Modifying the Microsoft Windows® registry in any manner, whether through the Registry Editor or programmatically, always carries some degree of risk. Incorrect modification can cause serious problems that may require you to reinstall your operating system. It is a good practice to always back up a computer's registry first before modifying it. If you are running Microsoft Windows NT® or Microsoft Windows 2000, you should also update your Emergency Repair Disk (ERD).

For information about how to edit the registry, view the "Changing Keys and Values" Help topic in the Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Information" topics in the Registry Editor (Regedt32.exe).

About Making Microsoft Windows Application Programming Interface (API) Function Calls

Before calling Microsoft Windows API functions, you should understand how arguments and data types are handled by the Windows API DLLs. Incorrectly calling Windows API functions may result in invalid page faults or other unexpected behaviors. For more information on calling Windows API functions, see the topic The Windows API and Other Dynamic-Link Libraries in the Microsoft Office XP Developer Online Documentation or the Microsoft Developer Network (MSDN) Library.

About Digital Code Signing

Many security-conscious users and administrators set their Microsoft Office XP security levels to High with the Trust all installed add-ins and templates check box cleared (located in the Security dialog box, Macro submenu, Tools menu), which is highly recommended. With these settings, a signed and trusted COM add-in or VBA macro will be loaded, and a non-signed COM add-in or VBA macro will be disabled automatically. The only time a user will be prompted to either enable or disable a COM add-in or VBA macro is when a COM add-ins or VBA macro is signed but the software publisher is not included in the Trusted Sources list.

Microsoft Authenticode® technology allows software publishers to digitally sign executable (EXE) files, ActiveX® control (OCX) files, cabinet (CAB) files, and dynamic-link library (DLL) files. For a step-by-step guide on how to digitally sign a COM add-in using Microsoft Authenticode technology, see the Digital Code Signing Step-by-Step Guide.

About Deployment of Managed COM Add-ins in Microsoft Office XP

To comply with Office XP security, managed COM add-ins (COM add-ins targeting the common language runtime) must be digitally signed, and users' security settings should be set to their highest levels. Additionally, you will need to incorporate into your managed COM add-in project a small unmanaged proxy called a shim. For details, see Deployment of Managed COM Add-Ins in Office XP.

About Strong Passwords

Strong passwords should contain:

  • Both lowercase and uppercase characters.
  • Numbers.
  • Symbols (such as #, $, %, and ^).
  • At least eight characters.

Strong passwords should not contain patterns, themes, or words found in a dictionary.

Examples of strong passwords include:

  • $tR0n9p@$s
  • G80dn[s$M4!

**Note   **You should change your password frequently, at least every one to three months. Do not record your password in any form.

Automating the Visual Basic Editor

In Microsoft Office XP, when calling the features of the Microsoft Visual Basic for Applications Extensibility 5.3 object model, you may receive an error message that programmatic access to the Visual Basic project is not trusted. To prevent this message from appearing, point to Macro on the Tools menu, and then click Security. On the Trusted Sources tab, check the Trust access to Visual Basic Project box. By checking this box, macros in any documents that you open can access the core Microsoft Visual Basic objects, methods, and properties, which represents a possible security hazard. The default behavior in Office XP is to not allow macros to programmatically access the Visual Basic object model. The recommended behavior is to check the Trust access to Visual Basic Project box only for the duration of a macro that accesses the Visual Basic object model. The Trust access to Visual Basic Project box should be unchecked after the macro has finished running.