Documentation or more info on these parameters?

Documentation or more info on these parameters?

• T*R*Z

  The urls we are talking about here refer back to the web control, not the report server.  So the various url parameters from the report server don't generally apply here.

  To address your specific concern, the url does not contain any information about the report path, nor does it accept any information about it.  The only piece that identifies the report is the session ID.  This is the report server session id.  Sessions are tied to a specific report.  But even if the user changed the session ID on the url, that session would have already needed to have been created on the server via some other mechanism.  And because sessions are tied to the user that created them, the user using the session ID must have already had access to the report.

  
  

• Matthew Gertz MS

  These urls are for internal use and are not documented anywhere.  Preventing spoofing of these urls is something we spent a lot of time on.  Is there something specific in there that troubles you   You'll notice that the url does not contain any information about the underlying report server.  In fact the only useful information to the report server is the session id, which the server will only allow to be used by the same user that created the session.
  

• German Mendoza

  Yes, someone monitoring the traffic could resubmit your session ID to gain access to the report as long as the session has not yet expired.  SSL is the way to counter this.  There are two channels to secure - from the client to the web server, and from the web server to the report server.  Using SSL on both would be your best bet.

  The only place the session ID would appear in clear text is in the contents of the html pages stored on a client cache.  There is nothing you can do to the control to prevent this, but I think it is a narrow case given the lifetime of the session.  Ultimately, you need to weigh that for yourself depending on the data you are sending and the attacks you anticipate.  You can decrease the session timeout on the report server from its default of 10 minutes.

  
  

• Bob Bannon

  Thank you for your feedback and quick response to my questions.

  Based upon this feedback, I now feel assured that there is no cause for concern in regards to client side hacking/spoofing.

  I wanted to communicate that our implementation of the report viewer control uses Windows impersonation within the ASP.NET ‘web.config’ file.  We cannot use Windows authentication per client due to the architecture of our product.

  That being said, it would appear possible for an unauthorized client to successfully request a report if they happened to know the exact session ID in progress on the reporting server.

  I could see how this would pose a potential security hole if someone on the Internet were able to view the session ID sent from the client.  Do you agree   If so, if our production server were to require a SSL connection do you feel that this would provide a secure implementation < xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

  
  

• Pyromanci

  Thanks for the response Brian.

  Before RS2005 came out we were playing around with URL Access in RS2000.  Through URLAccess there were a bunch of features you could do through parameters in a URL.  Amongst those parameters was the "Command" parameter to render new reports.  Is it possible for a user through those ReportViewer parameters to render a completely different report

  What we're worried about is a user who has access to one particular report spoofing the parameters and viewing/rendering another report that they were not supposed to see.

  thanks in advance, and once again I appreciate the response.

  
  

• salex

  Thanks Brian for all your help.  You've put to rest all of our concerns about the ReportViewer control.

  All the best, and happy holidays.

  
  
• Documentation or more info on these parameters?