Threat and Vulnerability Mitigation (Reporting Services)
This topic describes techniques and strategies to reduce threats to a Reporting Services deployment.
Overview
A report server is a stateless server that stores content and application data externally. One of the largest threats to a report server installation is unauthorized access to or tampering of the report server database and configuration files. A less obvious but equally important threat is in how you create reports and who has permission to publish content to a report server. Report definitions are assemblies that run in full trust on a server computer. Report definitions can contain other custom assemblies that also run on the server. If the report or a custom assembly contains malicious code, that code will run on the report server computer under the credentials of the user who requested the report. Other subtle threats can accrue through a report design that unintentionally exposes sensitive data. For example, if an employee runs a report that uses an employee ID as a parameter, he or she should not be able to view information about another employee by inserting a random ID into a report URL. Finally, consider the report distribution practices in your organization. You can configure a report server to minimize the possibility of delivering reports outside the organization. You can also use permissions on the file system and report server permissions to ensure that only authorized users can open a report.
The following sections in this topic describe additional threats and how you can minimize the risks of an actual exploit.
Mitigating an Attack on a Report Server
The following table describes threats and mitigations that affect server components and configuration settings.
Feature or operation |
Threat |
Mitigation |
|---|---|---|
Configuration settings are stored in Web.config and in application configuration files on the report server computer. |
An attacker might gain access to the computer, locate an unencrypted or unprotected configuration file, and tamper with the file. |
Set permissions on the file. By default, permissions are granted to Reporting Services security groups that are created during Setup. |
Report Server Web service processes on-demand requests sent over TCP/IP connections. |
An attacker might launch a denial of service attack that takes the following forms: Multiple unauthenticated requests are directed at a target server. Incomplete requests are directed at a target server but never completed. Requests are excessively large; the attacker starts a request and then sends a large payload to the server. |
The report server drops all unauthenticated requests within two minutes, which can minimize some of the effects of a denial of service attack. The two-minute interval is fixed; you cannot shorten it. If the attack is based on upload operations to the report server, you can reduce the value for maxRequestLength element in the Machine.config file. By default, ASP.NET places a megabytes (MB) limit on items that can be uploaded to a server application. Note that lowering the value for maxRequestLength should be a temporary measure. You should change the value back to its previous value if uploading large files (such as models) is a common practice. For more information about setting maxRequestLength in a Reporting Services installation, see Report and Snapshot Size Limits. |
Reporting Services supports an extensible architecture that lets you deploy third-party data processing, rendering, and delivery extensions. You can also deploy custom query designers. Extensions must run in Full Trust. |
An attacker might include malicious code in a custom extension. |
Only deploy extensions from users or organizations that you trust. |
Mitigating Threats to Reports Definitions and Report Models
The following table describes threats and mitigations that affect report definitions and model files.
Feature or operation |
Threat |
Mitigation |
|---|---|---|
Publishing reports, models, and shared data sources to a report server. Reports and models connect to and query external data sources. |
Intercepting reports, models, and shared data sources during a publish operation. Intercepting requests that are in transit to an external computer. |
Use a secure, encrypted channel, such as SSL/TLS/IPSec, for connection. Encryption technologies must be used to protect a channel. Inform users before sending that the channel is not secured. |
Authentication tokens or credentials are used to connect to remote computers and data sources. |
Intercepting authentication data when processing a request. |
Use a secure, encrypted channel. Inform the user if the channel is not secured. Follow the principle of least permission. Retrieving data used in a report requires read-only permissions on data sources. |
Report URLs show parameter values in the address bar of the browser window. |
If a report contains confidential data, do not add parameter values that can be tampered with on the URL. For example, if a parameterized report includes an employee ID, a user can insert a random employee ID on the URL to view data intended for other users. |
Before publishing a report for final distribution, check its URL to verify whether parameter values can be replaced with random values. When you design your reports, remember that there are no permissions associated with setting parameters. There are a couple of possible mitigations:
|
Reports and models contain data source information and queries. |
Disclosing information about a data source or its structure provides an attacker with internal information that could be exploited. |
Before letting a user to modify a report model, set model item security to restrict access to model items that you do not want the user to see in Model Designer. Set permissions on files. Files include .rdl, .rds, .smdl, .ds, .dsv, and .smgl files. By default, files that are stored locally in a user’s folder are accessible only to user groups and accounts defined on the local computer if the operating system is Windows XP or later. |
Report definitions and shared data sources contain data source connection strings. It is possible to include credentials in a connection string. |
An attacker might access database credentials stored in the database connection strings if the report files are compromised. |
Store credentials separately from the connection string. You can use the stored credentials option in the data source property pages to encrypt and store a user account and password. |
Reports and models are processed on demand. Reports can reference or contain custom assemblies. Reports can contain custom report items or third-party controls. Custom report item controls require Full Trust. |
An attacker convinces a user to run a report that exploits embedded Visual Basic code or database queries to execute arbitrary code with the user’s permissions. Running a report or model that has been tampered with can cause buffer overruns, crash a server, or worse. |
Limit the number of users who have permission to publish reports and models. Ensure that only authenticated users have permission to upload files. Ensure that users who author reports understand how to create scripts that can withstand SQL injection, script injection, and HTML injection attacks. Only upload or publish reports and models from people you trust. Only install or use a custom report item control from people you trust. Review files before uploading them to verify that any references to custom assemblies are valid. Set file permissions on assemblies so that they cannot be overwritten by malicious users. |
Previewing a report or model in the Preview tab in Report Designer creates cached data that is retrieved using the credentials of the author. |
Other users who preview a report on a report author's computer might be able to view report data that he or she would not otherwise see. |
Deploy reports to a test server or location when finishing a report design. |
General Steps to Mitigate Threats and Vulnerabilities
Apply the following best practice recommendations to enhance the overall security of any report server deployment:
Turn off unused features to reduce the surface area of attack. For more information, see How to: Turn Reporting Services Features On or Off.
Use SSL for report server connections. For more information, see Configuring a Report Server for Secure Sockets Layer (SSL) Connections.
Create a folder hierarchy that supports robust permission policies by placing sensitive or confidential reports in folders at the furthest branches of the folder hierarchy in folders that are accessible to a restricted set of users. Reports, models, shared data sources, and resources that you publish to a report server are secured through role assignments that you create on folders and specific items on the report server site. Because the folder hierarchy is fully user-defined, it is up to you to create a folder hierarchy that groups together any items that have similar user access permissions. For more information, see Securing Folders.
Understand that on-demand reports are compiled assemblies that run in full trust on a report server under the credentials of the user who opens the report. Report users who log on using local or domain administrator credentials and subsequently open a report that contains malicious script will inadvertently run that script with administrator permissions. Encourage users to use least-privilege accounts when viewing reports. For more information, see Integrated Security and Elevated Permissions.
Understand how data is retrieved and used in a report. If a report contains sensitive data, consider using models as a data source so that you can apply security filters and model item security. For more information, see Tutorial: Applying Security Filters to Report Model Items.
Understand how the report is distributed. Subscription and delivery features are powerful techniques for automating report processing and distributing a generated report, but to avoid unauthorized access you will want to monitor who has share permissions on network folders and evaluate report server e-mail configuration settings to determine whether you need to restrict e-mail distribution. For more information, see Controlling Report Distribution.