Security

Configure access control to all levels of the Pull Reports™ configuration hierarchy through the use of <access_control_voter>s. <access_control_voter>s reference an instance of the Catalog Configuration Java API AccessControlVoter class to control access to a <catalog>, <report>, <relationship>, <column>, or <canned_query>. Pull Reports™ maintainers must provide their own implementation of AccessControlVoter appropriate for their access control requirements.

Additionally, since <access_control_voter>s apply to all Pull Reports REST API requests, use of the Report Creator is responsive to access control configuration. This means users of the creator only see catalog configuration elements to which they have access.

Since the AccessControlVoter's vote method receives the Pull Reports REST API HttpServletRequest as an argument, access control may use any HttpServletRequest method such as getRemoteUser or isUserInRole. However, Pull Reports™ does not provide a security implementation to fulfill HttpServletRequest security methods but rather depends on the installation WAR. Two popular WAR security implementations which work with Pull Reports™ are JEE container security and Spring Security. It is the responsibility of the Pull Reports™ configurator to set up these security implementations.

See the <access_control_voter> documentation for more examples on how to use AccessControlVoters to secure Pull Reports™

Use a <subquery> element to restrict access to rows within a <table>. Similar to securing reports, securing Pull Reports™ via a <subquery> depends on the security implementation of the installation WAR.

For example, if using security implementation which supports the HttpServletRequest.isUserInRole(String) method, the following Pull Reports™ XML Catalog file customizes the export result based on user role. All users can export records from the cust_order table which have not yet shipped, but only users with the role SUPERUSER may export all records.

See the <subquery> element for more configuration options.

<?xml version="1.0" encoding="UTF-8"?>
<catalog xmlns="http://www.pullreports.com/catalog-1.6.1" id="customer" name="Customer Reports"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.pullreports.com/catalog-1.6.1
    https://www.pullreports.com/docs/xsd/pullreports-catalog-1.6.1.xsd">
    <report id="order" name="Customer Orders">
        <table id="order" displayName="Order"> 
            <subquery>
            select o.item_number,o.item_name 
            from cust_order o 
            where 
            ${(request.isUserInRole('SUPERUSER'))?'1=1':'o.shipped = false'}
            </subquery>
            <column id="item_number" name="item_number" displayName="Item Number" paramType="java.lang.Long"/>
            <column id="item_name" name="item_name" displayName="Item Name"/>
        </table>
    </report>
</catalog>

A <label_value_list> configures a list of label/value pairs which represent the possible values of a <column>. <label_value_list>s are used by the Report Creator Filters Tab to display the available values for a filter parameter. The GET Label Value List REST API returns the list of available values for a <column>.

Pull Reports™ provides two methods to contextualize the label values to the user using the Report Creator. The first is the use of a Groovy template within a <label_value_query> element. Since the HttpServletRequest is available as a template attribute, the configured label value query may be responsive to HttpServletRequest methods such as getAttribute, getRemoteUser, or isUserInRole.

See the the section called “Usage with <label_value_query> and a Groovy template” within the Pull Reports™ schema documentation for more information.

The second method is to use the Catalog Configuration Java API and configure a custom LabelValuesProvider for a ColumnConfigurationBuilder. Since the LabelValuesProvider createLabelValues method receives the GET Label Value List REST API HttpServletRequest, the returned label value list may also be responsive to HttpServletRequest methods.

In order to prevent SQL injection, Pull Reports™ passes all filter values as JDBC query parameters. This guards against the most common form of SQL injection in which user provided values are directly concatenated with a SQL statement and passed to the database unaltered.

However, Pull Reports™ does concatenate the name attribute of <column> and <table> Pull Reports™ XML Catalog file elements and analogous properties within the Catalog Configuration Java API within SQL queries. This means malicious SQL script in these attributes poses a SQL injection risk. In order to protect against malicious script within name attributes, Pull Reports™ prohibits the semicolon (;) within these two attributes.

The Export Report REST API is vulnerable to XSS attacks from malicious HTTP parameter values since it reflects those values back in the HTTP response of several REST API endpoints. In order to mitigate XSS attacks, the API strips suspect input patterns from all request parameters and headers. (Reference and thanks to: Ricardo Zuasti)

However, since the Export Report REST API returns data unaltered from the database, clients should take care to properly encode all output before including it in a web page if concerned about XSS.