Hiding parameters ?

5 posts, 0 answers
  1. Lars I
    Lars I avatar
    15 posts
    Member since:
    Dec 2017

    Posted 29 Mar Link to this post

    Hi.

    We use Telerik Report Server in connection with our web gis system, and users are managed in this system.

    When we fetch a report, it's done with a GET, which enables the user to "hack" the parameter values that are attached. This is not desireable.

    1st question: How come TRS only allows reports to be executed using GET ?

    Adding POST would enable us to hide the parameters.

    2nd question: Why does TRS add all parameters to the URL in the address bar, when executing the report, even those that aren't given originally and not visible ?

    This make hiding parameter values from users very difficult.

    Cheers.

  2. Lars I
    Lars I avatar
    15 posts
    Member since:
    Dec 2017

    Posted 05 Apr in reply to Lars I Link to this post

    Anyone ?
  3. Todor
    Admin
    Todor avatar
    269 posts

    Posted 10 Apr Link to this post

    Hello Lars,

    Indeed, the requests to fetch the report (i.e.Get Document and Get Document Page) are GET and contains the URL to the created resource, which holds report parameters and their values. This is done purposely, to allow for easier changing of parameter values directly in the URL, sending reports by sharing meaningful URL, etc. The other requests exposing directly the parameters (Get Report Parameters and Create Report Instance) are POST.
    The same is valid also for the Report Server Web API - the request for creating reports are POST.
    You may use Report Server Web API, for example through the Report Server API Client that we provide to manage the Report Server according to the specific requirements.

    The purpose of the Report Parameters is to allow the user to modify and filter the report depending on custom needs. Therefore, the Reporting/Report Server REST API has not been designed with the idea of hiding report parameters. Generally, the Report Parameters are not intended to hold sensitive information. You may utilize User Functions to relate a report parameter value to sensitive data, or create SQL Queries or Stored Procedures to fetch the sensitive data based on parameter values when processing the report.

    Regards,
    Todor
    Progress Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  4. Lars I
    Lars I avatar
    15 posts
    Member since:
    Dec 2017

    Posted 10 Apr in reply to Todor Link to this post

    I'm sorry to hear this, Todor.

    There's basically no difference between a GET and POST http request, except for the technical limitations of a GET. Using GET only to fetch and POST only to modify is just a convention, nothing more. Any GET request can easily be converted into a similar POST request. It only requires the backend to accept them.

    I do appreciate your desire to enable the user to change whatever parameters they want in the URL, except that this is not always preferable. Parameters can also be used inside the report to store "global" values in the report, but not as long as you're exposing them.

    Our issue is that our frontend handles multiple (10+) user profiles, each of which has its own sensitive information in their reports. But because the users can easily "hack" the url of the shown report (parameters _and_ report name), we're forced to create multiple almost identical reports, typically one for each user.

    And in some cases we've even been forced to rename the report names themselves to a random GUID to disable hacking.

    I would therefore again urge you to add the possibility to fetch reports using POST, so hiding parameters from a user would be possible. If some of the parameters should be exposed to the user, it may be done in the report itself.

    Alternatively, properties on a parameter, that control whether it should be exposed automatically or not, would be beneficial.

    Cheers

  5. Todor
    Admin
    Todor avatar
    269 posts

    Posted 15 Apr Link to this post

    Hi Lars,

    Thanks for the suggestions.
    Generally, we do not consider the type of the request (GET or POST) as related to security. Any user may use tools like Fiddler to check any request and get the values and names of the parameters from there.

    Starting with Telerik Reporting R1 2018 SP3 (12.0.18.416) we have exposed UserIdentity to be utilized in Expressions in the report. Instead of Report Parameter you may use the identity of the currently logged user to verify whether he/she is authorized to access particular data. You may consider using our built-in conditional functions and use the identity to make decision about the data fields, or create your own user functions and pass the identity to return data based on it.

    Regards,
    Todor
    Progress Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Back to Top