Protecting Sensitive Data

  • Article

Frequently, we find developers using InfoPath as a platform for developing solutions that manipulate sensitive data, may it be financial data, patient records, or performance review forms. This article shares tips on protecting such data.

 

First and foremost, you must know that an InfoPath form is a plain-text XML file. A malicious user can read it through Notepad or other text editor, circumventing any InfoPath authentication logic. So if a user has read access to an InfoPath XML form, anything stored in that XML file can be read. Information Rights Management in InfoPath 2007 allows storing encrypted XML; we'll talk more about it below.

 

Also remember that an InfoPath form template (.xsn file) is just a CAB archive, containing plain-text files. These files store all client-side form logic. Information Rights Management allows you to encrypt form templates in InfoPath 2007, see more about it below.

 

Like with any other client-server application development platform, you can never trust the logic that happens on the client. InfoPath uses the form template to store all form logic; if the user has access to the form template (and they must in order to be able to open any form based on that form template), they can create a hacked version of the template, circumventing any restrictions that the original form author put in place.

 

This means that authentication and authorization performed on the client can't be trusted; calculations and data validation have to be re-done on the server. Here is an example of how this strategy can be realized for a simple record-keeping application:

 

  • Do not store sensitive data in the XML file; instead, store keys in the XML file, and perform queries on load that populate the rest of the data by using a database/web service. If the user is unauthorized (as determined by the server-side logic), return an empty dataset. You can even detect such condition on the client and show a friendly error message.
  • On submit, send the data to a web service and redo all non-schema validations on the server side. For example, if employees should not be able to submit expense reports above $100 without specifying an approver, have your web service process the dataset and verify that this condition is satisfied. 

 

It is always a good idea to restrict access to a production form template by assigning read-only permissions to form users, write access to form maintenance staff, and no access to everyone else. This can be done by using permission features of the SharePoint Server or file shares. Even if you install form templates to the users' machines via a logon script, you can still control access to the .xsn file - provided the user is not running as an administrator, you can set their access to the template file to read-only.

 

You may want to enable the protection feature for production form templates:

 

 

However, remember that this protection feature is for recommendations only, it is not intended as a security mechanism. This will show the user a nice error message if they accidentally try to open the template in the Design mode, but won't defend the form template against a malicious user.

 

Information Rights Management, or IRM, is a new feature for InfoPath 2007; some of you may already be familiar with the concepts from the other apps in the Office 2003 release. IRM allows the form author to protect both the form template and forms based on the template; IRM infrastructure must be in place in the organization to make this possible. Briefly, IRM is a way to encrypt both form templates and forms, allowing form author to specify who can access the template and suggest default rights for forms based on the template:

 

 

Note that IRM is an InfoPath client-only feature, and it will not work in browser-enabled form templates.

 

Alex Weinstein

Program Manager