Overview of Security in InfoPath

 < Day Day Up > 

The flexibility of InfoPath 2003 brings with it several potential security concerns. The designers of InfoPath have included processes to protect users from malicious code and other security issues. For example, InfoPath allows users of a form template to save the form to their hard disk, enabling them to fill in an InfoPath form even when disconnected from the Internet. Normally, a local application would have full rights to save or delete files on the local machine. Because the form template originally came from another domain, such free access to system resources could pose a security risk.

In addition, InfoPath can, under certain conditions, read from or write to the user's hard disk and submit information to a designated URL on a remote server, which creates potential security risks. It is therefore important that a user be protected from such security risksmalicious code, for example, in the event that such code might be present in an InfoPath form template.

In light of these security concerns, not all InfoPath form templates are allowed full access to local system resources. Form templates that are allowed full access to system resources on the user's machine are called fully trusted forms . Before a form can be recognized as fully trusted, it must be explicitly installed on the user's machine (techniques for such installation are described later in this chapter). It makes sense that a user has to decide whether to trust such form templates, because they have the potential to misuse confidential data on the user's machine. Installing a fully trusted InfoPath form template has implications similar to installing a program you might have downloaded on the same machine. For example, you need to decide whether you trust the source of the software and whether to install it.

Forms that are not fully trustedwhich are sometimes called sandboxed form templates or URL-based form templates are given access to the user's machine as determined by the Internet Explorer security zone for the URL from which the form template was originally downloaded. The original URL is expressed in the publishUrl attribute of the xsf:xDocumentClass element in the form definition file (the .xsf file).

To learn more about the manifest files xsf:xDocumentClass element, see "The <xsf:xDocumentClass> Element," p. 279 (Chapter 16).


SHOP TALK
INFOPATH SECURITY

InfoPath security has led to many questions on the InfoPath newsgroup ( microsoft.public.infopath using a newsreader on the msnews.microsoft.com news server). In part, the problems arise from expectations among users that InfoPath forms are very similar to traditional HTML formswhich, as discussed in earlier chapters, they are not. Difficulties also arise because many developers seem not to have grasped how InfoPath uses a combination of Internet Explorer security zones and security levels in the InfoPath object model. To add to a potentially confusing mix, InfoPath was released only a few months after Windows Server 2003, where the assumptions in favor of security over ease of use were significant. Also, InfoPath was designed to be used with the Windows SharePoint Services, which had more than a few changes from its predecessor, SharePoint Team Services.

Taken together, these issues mean that you need to pay close attention to InfoPath security to avoid losing confidential data or allowing malicious code to gain access to your machine or those machines for which you are responsible. At the same time, users need to be able to use InfoPath form templates to achieve business needs.


Security Risks of InfoPath Forms

I won't attempt to provide an exhaustive account of all possible security scenarios in the space available. Among the security issues that could occur in association with InfoPath forms are the following:

  • Disclosure of sensitive information

  • Cross-domain data access

  • Malicious use of ActiveX controls

  • Malicious use of InfoPath object model properties or methods

  • Use of external data sources

  • Protection of form template design

Let's look briefly at each of these potential risks in turn .

Disclosure of Sensitive Information

When you use your own computer, you naturally expect to be able to manipulate its files and information, including deleting data and sending data to machines in other domains when appropriate. You carry out such tasks using programs installed on your computer, applying your knowledge to avoid inappropriate actions.

INTERNET EXPLORER SECURITY ZONES

The security zones provided in Internet Explorer are described in the "InfoPath Security and Internet Explorer" section later in this chapter.


Imagine a scenario in which you download an InfoPath form template from the fictitious domain http://www.distinctlyDodgy.com and save it to your hard disk. If InfoPath provided no security precautions , that form might be treated as coming from Internet Explorer's implicit Local Machine security zone. Local applications are normally trusted, so in the absence of added security measures, a form from http://www.distinctlyDodgy.com is given access to your machine as if it's a local application. However, the application logic was possibly written by somebody you might not know or trust. Of course, it is also possible that you trust http://www.distinctlyDodgy.com , but just as likely a typical user might not realize the extent of access she is giving to what amounts to an application from a remote domain. For example, if an author on http://www.distinctlyDodgy.com has written malicious code, then confidential information on your computer can be accessed and sent to a remote recipient, potentially with the user unaware that anything undesirable is happening.

Fortunately, InfoPath has an approach to handling form templates from remote or untrusted sources. InfoPath uses the form template's origin URL as its point of reference in making security decisions at all times. So even if a form template from http://www.distinctlyDodgy.com is saved to your hard disk, it will in effect be assigned to Internet Explorer's Internet zone, which is likely to be trusted much less, thus reducing any risk of loss of confidential information (unless you have for some reason explicitly assigned http://www.distinctlyDodgy.com to the Trusted Sites zone, for example). Of course, the precise degree of protection provided depends on whether and how the user has altered the default settings for those zones.

Cross-Domain Data Access by Email

If you are sent an email containing a form template from the fictitious domain http://www.distinctlyDodgy.com , it is possible that the form template contains scripting code that can use your identity and authorization to access data to which you (the user) have legitimate access, but that nobody on the remote domain should have access to. Assuming that the form template is assigned to the Internet zone (in other words, that you don't assign the form template's URL to Internet Explorer's Trusted Sites zone), you will be protected by the Access Data Sources Across Domains setting by default.

To view or alter the Access Data Sources Across Domains setting, follow these steps:

  1. Select the InfoPath Tools menu and select Options.

  2. On the General tab of the Options window, click the Internet Options button (or select the Internet Explorer Tools menu and select Internet Options). The Internet Options window opens.

  3. Select the Security tab (see Figure 12.1).

    Figure 12.1. The Internet Options Window Security tab.

    graphics/12fig01.jpg

  4. Click the Custom Level button. The Security Settings window opens.

  5. Scroll down to the Miscellaneous section (see Figure 12.2). Access Data Sources Across Domains is the first option in that section. In the Internet zone, that functionality is disabled by default.

    Figure 12.2. The Miscellaneous section of the Security Settings window.

    graphics/12fig02.gif

By contrast, the Access Data Source Across Domains setting is, by default, Prompt for the Intranet zone and Enabled for the Trusted Sites zone.

Unless there are very good reasons to the contrary, form templates created in a remote domain should at least be protected by setting the Access Data Source Across Domains settings to Prompt or Disable. The Disable setting is preferable in many circumstances because most users won't appreciate the implications of responding in the affirmative to a request to allow cross-domain data access.

Malicious Use of ActiveX Controls

A malicious ActiveX control can delete files or access confidential files that might contain passwords or other sensitive information. Scripting code in a malicious InfoPath form template can make use of such a malicious ActiveX control to cause unwanted actions without a user's consent . Malicious scripting code can be present in the main script file of the form template, script.js or script.vbs , or in scripting code in a custom task pane.

In the Internet Explorer security settings, the Initialize and Script ActiveX Controls Not Marked As Safe setting is located in the ActiveX Controls and Plug-ins section of the Security Settings window (see Figure 12.3).

Figure 12.3. The Initialize and Script ActiveX Controls Not Marked As Safe section in the Security Settings window.

graphics/12fig03.gif

There are three options for the settingDisable, Enable, and Prompt. The Initialize and Script ActiveX Controls Not Marked As Safe option is set to Disable by default in the Internet zone, the Local Intranet zone, and the Restricted Sites zone. URLs in the Trusted zone have the default setting of Prompt. To fully enable the use of ActiveX controls, you need to use fully trusted InfoPath form templates, which are discussed later in this chapter.

Malicious Use of the InfoPath Object Model

Certain methods of the InfoPath object model can potentially be used for malicious purposes. For example, the SaveAs() method of the XDocument object can be used to save data to the user's machine. To guard against this, InfoPath has a three-level security model, which is described later in this chapter.

Using External Data Sources

You saw in Chapter 4, "InfoPath Form Controls," how a secondary data source can be used to populate a drop-down form control. Use of secondary data sources or other sources of external data can potentially pose security risks.

When you are designing form templates, it is good practice to avoid passing data from an external data source to the JScript eval() method or to the innerHTML property of a custom task pane. You should make sure that any use of these makes use of trusted XML data.

SCRIPT IN XSLT STYLESHEETS

The XSLT stylesheets that are used to dynamically create InfoPath views cannot run script, so they do not pose a security risk the way that the JScript eval() method and the innerHTML method of a custom task pane can.


Protecting Form Template Design

One of the simplest pieces of security protection that InfoPath provides during the design of a form template is the ability to prevent users from changing the design of a form template. To disable form customization, you use the Form Options option in the Tools menu, which opens the Form Options window (see Figure 12.4).

Figure 12.4. The Form Options window.

graphics/12fig04.gif

In the Protection section of the Form Options window, a single check box is available that turns off the automatic protection InfoPath would provide.

Avoiding Unnecessary Error Messages

In attempting to protect the user from, for example, cross-domain data access, the InfoPath client can display potentially irritating error messages or warnings. As a developer, you should minimize the number of unnecessary error messages that are displayed, not least because you might get time-consuming support calls from users who want help deciding what to do when they are faced with such messages.

Because cross-domain data access is one potential cause of warnings (depending on Internet Explorer security settings), you should try to minimize or avoid cross-domain data access by ensuring that the form template and its data sources are located in the same domain.

PROTECTION AND THE UNIVERSAL INFOPATH CLIENT

End users can modify InfoPath form templates, and you need to discourage them from doing so. This is a result of Microsoft's decision to require that end users have the full InfoPath client, which itself has design functionality.


ActiveX controls that aren't marked as safe for scripting are another potential cause of warnings. If possible, their use should be avoided or minimized. Alternatively, use ActiveX controls in fully trusted form templates.

Because Internet Explorer security zones form such a foundational part of InfoPath security, we will review those zones and other aspects of Internet Explorer in the next section.

 < Day Day Up > 


Microsoft Office InfoPath 2003 Kick Start
Microsoft Office InfoPath 2003 Kick Start
ISBN: 067232623X
EAN: 2147483647
Year: 2004
Pages: 206

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net