This document addresses security implications related to storing and distributing report layouts and describes best practices to help you and your end-users understand reporting security.
Possible risks include leaking sensitive data contained in serialized reports and executing harmful code injected into them by third parties. The following sections describe how to eliminate these risks.
Opening reports from untrusted sources in a Print Preview or Report Designer may trigger uncontrolled execution of harmful code injected into these reports:
A report saved using a legacy serialization mechanism contains code that is compiled and executed when this report is loaded in a Report Designer. Injecting code into a report results in its uncontrolled execution on the client.
We strongly recommend that you do not change the default behavior and continue using XML serialization for saving reports.
Unlike the legacy CodeDOM serialization, XML is protected against injecting harmful code into a report's definition and executing it on a client machine when deserializing such report.
We recommend switching to XML serialization instead if your application still uses CodeDOM serialization.
A report is considered dangerous on finding any of the following content in it (or in any of its subreports):
Regardless of which serialization mechanism was used for saving a report, it may still include executable code contained in report scripts. Enabling report scripts on the client exposes your end-users to the risk of executing harmful code on their machines.
End-user desktop and web reporting applications have different security settings by default:
Report scripts can never be considered entirely safe, and their execution cannot be completely restricted.
In particular, assigning security permissions to report scripts does not restrict them from accessing the .NET framework's static variables and methods.
Calling the XtraReport.CreateDocument method to export a report or load its Print Preview triggers the uncontrolled execution of any code injected into the report's scripts on the client machine. This code is executed in the application's domain with full privileges granted to the application.
See Scripts Security for more information.
Consider the following to prevent exposing sensitive information contained in report definitions:
Protecting Data Source Information
Unlike published report documents, a report definition does not store the actual values from a report's data sources. It can only include general information about a report's data sources and report elements' data bindings.
A report definition only stores the data connection name by default. It does not include any sensitive information related to data connections (both the user's credentials and connection string is saved to your application's configuration file by default).
A report definition can contain information about the data source schema (as Base64-encoded text), which includes names of selected data source tables, views, and columns.
You can handle the XtraReport.SaveComponents event to access and manage the list of serialized components.
Protecting Password Information
A report definition file stores PDF and Excel passwords in clear text.
After specifying these passwords in a report's XtraReport.ExportOptions, all PDF and Excel files created from this report use these passwords by default.
Leaking the original report definition containing passwords specified for its export options exposes all PDF and Excel documents produced from this report using these passwords.
Avoid specifying default passwords for a PDF and Excel export and restrict access both to report definition files exposing these passwords and the PDF and Excel documents' storage.
Take the necessary measures to protect your reports and restrict access to their storage.