Internet Explorer implements security zones that allow you to control the level of access given to your computer by the Web pages that you open. InfoPath uses some of these zones to determine the level of access that forms are given to the resources on your computer. By default, InfoPath forms run in a cached location that is denied access to critical system resources. Forms that are allowed full access to system resources are called fully trusted forms. Fully trusted forms are usually installed and registered by using an installation program such as Microsoft Windows Installer (MSI) so that they can be granted a higher level of permissions.

InfoPath cached forms are identified by the URL or URN specified in the form's form definition file (.xsf). The type of identification used and the domain (location) from which the form template is opened determines which Internet Explorer security zone permissions the form will inherit. Forms identified by a URL are cached to the user's computer, allowing for offline use of the form. These URL-based forms inherit their security permissions, as well as their specific access rights, such as cross-domain access, from the Internet Explorer security settings applicable to the original location of the form template. Form templates stored on a Web server or a server running Microsoft Windows SharePoint Services run in the Internet or the Local intranet zone, depending on the server's domain. Installed forms that are identified by a URN, on the other hand, inherit their permissions from the Local Computer zone, which grants a level of permissions similar to that for HTML application files (.hta).

Fully trusted forms are identified by their URN and whether the requireFullTrust attribute of the xDocumentClass element in the form definition (.xsf) file is set to "yes". In Microsoft Office InfoPath 2003, when fully trusted forms are installed, they appear on the Custom Installed Forms tab in the Forms dialog box, which can be opened by clicking More Forms in the Fill Out a Form task pane. However, note that this is not the case in Microsoft Office InfoPath 2003 Service Pack 1, because the dashboard will be displayed instead.

For a detailed discussion of how fully trusted forms work and how to create and deploy them, see Understanding Fully Trusted Forms.

The ability to use trusted forms can be enabled or disabled on individual computers. When a computer is configured to trust installed forms, users can fill out forms that require access to their computer's resources.

In InfoPath 2003, you configure a computer to trust installed forms by using the Allow forms that I install with a custom setup program to have access to files and settings on my computer check box on the General tab of the Options dialog box, which is available from the Tools menu in design mode. With InfoPath 2003 Service Pack 1, you configure a computer to trust installed forms the same way. However, note that the Allow forms that I install with a custom setup program to have access to files and settings on my computer check box string in InfoPath 2003 Service Pack 1 now reads Allow fully trusted forms to have access to files and settings on my computer.

The InfoPath security model helps protect users against the following threats posed by maliciously authored templates:

• The potential for disclosure of sensitive information from My Computer or remote data sources.
• The malicious use of ActiveX controls.
• The malicious use of properties and methods from the InfoPath object model.

Cross-domain data access

The most common scenario for the disclosure of sensitive information is when a malicious user creates a form that uses the current user's security credentials to access a data source on a domain other than the one on which the form itself was deployed. For example, the malicious user sends a form in an e-mail message, or by using a URL to a form on a private share or Web server. The form contains script that performs a data access request by using the current user's credentials to retrieve data from a data source in another domain that the malicious user would not otherwise have access to, such as a database of payroll or other sensitive information. This class of security risk scenarios is referred as cross-domain data access.

The Internet Explorer security model that Microsoft InfoPath is built upon provides a setting called Access data sources across domains. By default, this setting disables cross-domain access for InfoPath forms that reside in the Internet and Restricted sites security zones. It prompts the user to allow or disallow cross-domain access for InfoPath forms that reside in the Local intranet security zone, and it enables cross-domain access for InfoPath forms that reside in the Trusted sites or My Computer zones.

Use of the InfoPath task pane

The InfoPath task pane allows for the rendering of Web pages, such as .htm, .asp, and .hta files. The pages referenced from task panes can be located inside or outside of the form template. The only restriction on what can be referenced from outside of the form template is that the Web page must be in the same domain as the form template, or the security zone in which the template resides must allow cross-domain access permissions to load the task pane.

The task pane does not expose an address bar or status bar, and as a result, the user has no way of confirming the location of the source for the task pane or whether that location is being accessed over a secure connection (https). For this reason, you should avoid using the task pane for displaying or entering sensitive information. The task pane was designed for displaying dynamic help information and controls for navigating between views and other elements of an integrated solution. Additionally, a form template's script file (script.js) and script in the task pane can interact with each other. This interaction is allowed, however, only if the form template and the task pane are in the same domain, which helps prevent information from being exchanged across domains.

Cross-domain data access prompts

If a form template that requires cross-domain data access is located in a security zone that is set to prompt for cross-domain data access (the default setting for the Local intranet zone), then the user will be prompted about allowing access. The user's choice will then persist for the remainder of the time that the form is opened. If you must deploy InfoPath form templates that require cross-domain data access, you should deploy these templates as fully trusted forms, or make them available on a server that is in the Trusted sites security zone, to avoid prompting users to allow access. (Continual prompts to allow access can effectively train users not to be concerned about this security risk.) Users should not be instructed to lower the security level of the Local intranet zone to avoid these prompts.

Forms without a publishURL attribute

If InfoPath loads a form template from the local computer and it has a blank publishUrl attribute or the attribute is missing, the form will be placed in a more restrictive security zone. This is done to mitigate the threat of a malicious form template being distributed by e-mail. As a result, if the user saves this form template to disk, it will not be able to run with the permissions of a form that resides in the My Computer zone.

Unsafe ActiveX controls

The most common scenario for the malicious use of ActiveX controls can occur if an author uses script with an ActiveX control that provides methods for accessing the file system to retrieve personal files and password lists, to delete files, or to disable the user's system. An InfoPath form can use ActiveX controls only from script in the main scripting file of a form (script.js) or from script in a task pane. InfoPath does not allow script in InfoPath views to run ActiveX controls.

The Internet Explorer security model that Microsoft InfoPath is built upon provides a setting called Initialize and script ActiveX controls marked as unsafe that, by default, results in the following actions for InfoPath forms or task panes that attempt to initialize and script ActiveX controls that are marked as unsafe for scripting.

Malicious use of the InfoPath object model

Similarly to ActiveX controls called from script, InfoPath methods and properties called from script can present different levels of risk. For example, the SaveAs method of the XDocument object can be used to write data anywhere in the file system.

To help protect against malicious use of InfoPath object model members, the InfoPath object model implements three levels of security that determine how and where a particular object model member can be used. There are three security levels in the InfoPath object model:

• 0  Object model members that can be accessed without restrictions. These object model members are safe and therefore can be accessed without restrictions.
• 2  Object model members that can be accessed only by forms running in the same domain as the currently open form, or by forms that have been granted cross-domain data access permissions. Restricted form templates that call security level 2 object model methods will only succeed if they are accessing resources contained in the form template itself.
• 3  Object model members that can be accessed only by fully trusted forms.

Notes

• Each of the topics for the properties and methods in the InfoPath Object Model Reference contains a security section that specifies the security level that applies to that object model member.
• Security level 1 is reserved for future use.

Summary

The following table summarizes the default permissions for each method of form deployment in InfoPath 2003. Permissions are based on the security zone for the domain from which the form template originates.

For InfoPath 2003 Service Pack 1, the default permissions for each method of form deployment are summarized in the table below. Similar to InfoPath 2003, the default permissions are based on the security zone for the domain from which the form template originates.

Note  One main difference between InfoPath 2003 and Service Pack 1, however, is that with Service Pack 1, a form template on your local computer will run in the "Local intranet" security zone unless it is locally installed or fully trusted.

For information on general security guidelines when developing forms, see Security Guidelines for Developing InfoPath Forms.

InfoPath provides other security measures for forms, including protecting form design, using digital signatures, managing certain form operations such as merging and submission, and trusting installed forms. The following sections describe these form security measures and where they are enabled in InfoPath.

Digital signatures

The data contained in a form can be digitally signed to help ensure that its contents are not altered.

You configure a form to use digital signatures by selecting the Allow users to digitally sign this form check box on the Security tab of the Form Options dialog box, which is available from the Tools menu in design mode. Users sign and verify forms by using the Digital Signatures dialog box, which is available from the Tools menu in design mode. Users can also sign and verify forms by using the Digital Signatures dialog box when filling out the form. When the form is opened again, the user will be alerted if the contents of the form have been altered.

Digital signatures additions

In InfoPath 2003 Service Pack 1, the digital signature feature has been enhanced and improved as follows:

• Digital signatures can be enabled for the entire form or for specific sets of data in the form that can be signed separately.
• You can choose to sign only specific portions of a form instead of the whole form.
• You can specify whether to allow single or multiple signatures. You can also specify what the relationship is for each set of data that can be signed. For example, you can specify whether the signatures are parallel cosignatures or whether each new signature countersigns all the earlier ones.
• A digital signature object model has been added that you can use to programmatically add custom information to the signature block in a fully trusted form.
• You can increase the security of digital signatures by capturing and including additional information, such as a timestamp, as non-repudiation evidence. Because the additional evidence is part of the signature, it cannot be removed without invalidating the signature. You can at any time recall or examine the captured data by clicking on a digital signature in the form, or by selecting a digital signature from the list of digital signatures displayed in the Digital Signatures dialog box.
• You can insert and see a signature in the document, and view the form as it was presented to each signer.
• The digital signature also includes a snapshot of the view as it was presented to the signer when the form was signed. The snapshot is stored as a base64-encoded image in the standard PNG file format.
• There is also a new option for partial signatures available in the Digital Signatures tab of the Form Options dialog box when in design mode.

Signed form templates

In InfoPath 2003 Service Pack 1, you can digitally sign a form template that you design. You can set the security level of the signed form template to either Restricted, Domain, or Full Trust.

A full-trust form template that is digitally signed will have the same access to system resources as a fully trusted form. (For a detailed discussion of how fully trusted forms work and how to create and deploy them, see Understanding Fully Trusted Forms.) Unlike an unsigned full-trust form that must be registered, a signed full-trust form template does not have to be registered. Therefore, an installer package (.msi) or script is not needed to deploy a signed, full-trust form template, because no registration needs to be done. Using and deploying a signed, full-trust form template can be an alternative to using and deploying a fully trusted form. Whichever option you choose, you get similar security levels.

With signed, full-trust form templates, you will be able to take full advantage of the InfoPath object model. Like fully trusted forms, signed full-trust form templates are exposed to a richer set of coding functionality, which means you get all the richness of the application-level programmability and flexibility. In addition to the programming benefits, signed, fully trusted form templates also benefit from feature enhancements in InfoPath 2003 Service Pack 1, such as the ability to publish to a location and get automatic update functionality.

By digitally signing a full-trust form template, users of your template can be assured of the template creator's identity and that the template has not been altered since it was created. The digital signature security infrastructure uses a hierarchical system of trusted authorities to verify that someone who claims to be a software publisher of a form is indeed its publisher. If the verification is successful, only then is the form template allowed to open. Otherwise, the form will fail to load, which also means that if it contains malicious code, it cannot do any damage to the client computer because it has not been allowed to run.

To create a signed, fully trusted form template in design mode, you must have a certificate from a trusted root.

When users open a signed, full-trust form template, they will receive a certificate acceptance dialog, if the certificate used to sign the full-trust form template is from a publisher not in their trusted publishers list. If the publisher is not already in the trusted publishers list, users will have the choice to select the Always trust files from the publisher and open them automatically check box and then click Open. If selected, this option will add the publisher to the trusted publishers list. Once the publisher has been added to the user's trusted publisher list, the user will not be prompted again to accept or decline a form template signed using that particular publisher's certificate.

Two conditions must be verified before InfoPath will allow a form based on a digitally signed form template (.xsn) file to run as a fully trusted form:

• The signature on the template must be valid and trusted.
• The certificate used to sign the template must belong to a trusted publisher.

If either of these conditions is not met, the form will not be allowed to run. If the form template has been tampered with, thus rendering the digital signature on the form template invalid and unverifiable, or if the certificate used to sign the form template has expired or been revoked, the certificate acceptance dialog will not be displayed. The form template will fail to load, and a security warning error dialog will be shown instead.

For additional discussions on signed, fully trusted form templates, see Deploying Signed Form Templates.

E-mail deployment

In InfoPath 2003 Service Pack 1, you can deploy your form templates as an attachment to an e-mail message and move the form templates from one location to another. Mail deployment is an easy and effective way to distribute forms for interoffice use as well as to deploy forms to remote users.

You can digitally sign a form template that you design and then set the security level for that form template to Full Trust. Additionally, signed fully trusted forms, when deployed as an e-mail attachment, can be updated more easily and efficiently.

All forms in the InfoPath designer are created with an identity. This information helps InfoPath associate forms with form templates in the cache and retrieve updates to forms when they are posted to a shared location. By default, InfoPath creates two identities for form templates: a Form ID and an Access Path (also known as the publishURL attribute). You can find more information about e-mail deployment in the Security Levels, E-mail Deployment, and Mobile Form Templates topic in this SDK.

ActiveX controls

InfoPath 2003 Service Pack 1 supports hosting ActiveX controls in forms. The ActiveX controls can be preexisting (with some constraints) or can be written specifically for use with InfoPath 2003 Service Pack 1. ActiveX controls used in InfoPath forms are not downloaded automatically from Web sites. Instead, CAB files for the ActiveX controls that are not already present on the user's computer must be added to the form template file.

When an ActiveX control is used in a form and the control is not registered on the user's computer, the behavior when the form is opened depends on the ActiveX control settings within the form. If no CAB file is included in the form template file, InfoPath will not open the form. If the CAB file is present in the form template file, InfoPath will initiate an install process. For InfoPath to install a CAB file, the file must be signed, and the signature must be from a trusted publisher. If the publisher is not already in the user's trusted publisher list with a certificate present (with a trust chain leading to a trusted certificate root), the user will be prompted to either accept or decline trusting the publisher. If the user chooses not to trust the publisher, the CAB file for the control will not be installed, and InfoPath will not open the form.

ActiveX controls will not be installed by, or run in, forms that have only the Restricted security level setting. You can find a tutorial on how to write and deploy a custom ActiveX control created specifically for InfoPath in Lab 6: ActiveX Controls in InfoPath 2003 on the Office Developer Center Web site.

Note  ActiveX controls must be marked as "Safe for scripting" and "Safe for initialization with untrusted data" in order to be used in InfoPath.

.NET security

In InfoPath 2003 Service Pack 1, managed-code form templates support the same security levels as script running in unmanaged-code form templates. They also support additional code access security features that apply to managed code running under the Common Language Runtime (CLR) of the Microsoft .NET Framework.

If your form is fully trusted, it can automatically access resources outside the form template. Any assembly can be used in the business logic code. You can customize the permission set that is added to a managed-code form template using the Microsoft .NET Framework Configuration Tool or the Code Access Security Policy tool (Caspol.exe). InfoPath will look for a predefined code group and will apply the permissions set defined under that group to the application domain (AppDomain) where the managed code is loaded and from which it runs. Custom .NET security policies must be deployed to client computers where the managed-code form template will run.

Note that .NET security grants the Internet permission set only to managed code running in Internet Explorer Trusted Sites. Therefore, InfoPath managed-code forms will not run if they are published to a Trusted Site.

You can find more information about InfoPath managed-code form templates security in the documentation for Microsoft Office InfoPath 2003 Toolkit for Visual Studio .NET. To view the documentation, you will need Microsoft Visual Studio .NET 2003 and the Microsoft Office InfoPath 2003 Toolkit for Visual Studio .NET installed on your computer. You can download the Microsoft Office InfoPath 2003 Toolkit for Visual Studio .NET from the Office Developer Center Web site.

Form design

The design of your forms can be protected by enabling form protection. When form protection is enabled, users will be unable to modify the form template when filling out a form.

Note  Using this setting does not lock the form completely; it only disables the ability to open a form for design when filling it out. Users can still design a form by opening it directly from design mode, but they will receive a prompt indicating that the form is protected.

You enable form protection by selecting the Enable protection check box on the General tab of the Form Options dialog box, which is available from the Tools menu in design mode.

Merging forms

You can disable the form merging feature to prevent users from importing data from multiple forms into a single form.

You enable or disable form merging by using the Enable form merging check box on the General tab of the Form Options dialog box, which is available from the Tools menu in design mode. When form merging is disabled, users cannot click Merge Forms on the File menu when filling out a form.

Submitting forms

You can disable the form submission feature to prevent users from submitting forms.

You enable or disable form submission by using the Submitting Forms dialog box, which is available from the Tools menu in design mode. When form submission is disabled, users cannot click Submit on the File menu when filling out a form.

More information on security features is available in the InfoPath 2003 Help.