InfoPath Form Security Model
For information on working with digital signatures in Service Pack 1, see Digitally Signing Data in InfoPath Forms.
The Microsoft Office InfoPath 2007 security model is based on the security model implemented by Windows Internet Explorer. The Internet Explorer security model helps protect your computer from unsafe operations by using security zones and levels. Working in conjunction with the Internet Explorer security model, InfoPath provides for two kinds of form deployment that affect how an InfoPath form works within this security model.
- URL-based Forms This deployment method is the default when publishing a form from InfoPath to a Web server, Windows SharePoint Services 3.0 form library, or file share. These forms are referred to as URL-based forms because a user typically opens the form from the URL where the form is published, and the form has that URL specified in the publishUrl attribute of the xDocumentClass element in the form definition file (.xsf). URL-based forms are said to be sandboxed, because they have restricted access to system resources and other potential areas of risk. A URL-based form has the same level of permissions as a Web page that is opened from the same location as the form template file (.xsn).
- URN-based Forms This deployment method is for forms that require a higher level of access to system resources and other external resources, such as ActiveX controls and other software components. You can deploy InfoPath forms as fully trusted forms. Such forms are also referred to as URN-based forms because, instead of specifying the publishUrl attribute, they specify a Uniform Resource Name (URN) in the name attribute of the xDocumentClass element in the form definition file (.xsf). This class of form can request full trust if the requireFullTrust attribute of the xDocumentClass element is set to "yes" in the form definition file (.xsf). URN-based forms must be registered on the client computer by an installation program or script. In this case, the form gets the same permissions as an application running on the local computer.
In conjunction with these two methods of form deployment, every method and property in the InfoPath object model has a security level that controls when that method or property can be called from script running from the form.
Understanding InfoPath integration with the Internet Explorer security model
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), or they are digitally signed 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 Office InfoPath 2007, when fully trusted forms are installed, they appear on the All Forms tab in the Fill Out a Form dialog box, which can be opened by clicking Fill Out a Form on the File menu.
For a detailed discussion of how fully trusted forms work and how to create and deploy them, see Understanding Fully Trusted Forms.
Trusting installed 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 Office InfoPath 2007, you configure a computer to trust installed forms by using the Allow fully trusted forms to run on my computer check box on the Trusted Publishers tab of the Trust Center dialog box, which is available from the Tools menu in design mode.
Using security features in InfoPath
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. 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.
|Fully trusted form||Enable|
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.
- 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.
The following table summarizes the default permissions for each method of form deployment in InfoPath. Permissions are based on the security zone for the domain from which the form template originates.
|Security Zone||URL-based||URN-based||ActiveX Marked Unsafe for Scripting|
|Fully trusted form||X (signed by a Trusted Publisher)||X||Enable|
|Fully trusted form||X||Enable|
|Restricted||X||No ActiveX (except a limited hard-coded list)|
|Restricted||X||No ActiveX (except a limited hard-coded list)|
|Restricted||X||X||No ActiveX (except a limited hard-coded list)|
For information on general security guidelines when developing forms, see Security Guidelines for Developing InfoPath Forms.
Understanding other security features
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.
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 Digital Signatures section of the Form Options 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, which is available from the Tools menu, 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 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 an option for partial signatures available in theDigital Signatures section of the Form Options dialog box when in design mode.
Signed form templates
In InfoPath, 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 benefit from the ability to be published to a shared location and receive automatic updates of the form template when it changes.
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.
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.
InfoPath supports hosting ActiveX controls in forms. The ActiveX controls can be preexisting (with some constraints) or can be written specifically for use with InfoPath. 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 must be marked as "Safe for scripting" and "Safe for initialization with untrusted data" in order to be used in InfoPath.|
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.
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.
|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 section of the Form Options dialog box, which is available from the Tools menu in design mode.
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 section 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.
You can disable the form submission feature to prevent users from submitting forms.
You enable or disable form submission by using the Form Submit Options 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.