Qlik Community

QlikView Security & Governance

Discussion Board for collaboration on QlikView Security and Governance.

Not applicable

Continued Security Flaws! 3 years and counting!

We have struggled with Qlikview security and session timeouts for our off-site employees for the past couple of years. Currently, we use a VPN connection to secure access to the QV server and report data for our off-site employees, but bandwidth limitations make it difficult to access large amounts of report data for some of them. 

I think we can agree that there is a problem with the way basic security has been implemented with the Qlikview web solution because session timeouts do not ask a user to re-authenticate.  We recently worked with a web developer to review the code and make a recommendation for securing the site properly. 

Here’s how QV is working currently.

  1. When a session times out, the session data is removed from the QlikView server.
  2. When the same client in step one tries to reload, hit back, or click on an object or report the browser (which has the credentials information cached) re-submits the data and QlikView allows the re-authentication to take place successfully. This effectively loads whatever the client was trying to load without ever taking you to a Login Page. It behaves as though the session never ended.
  3. If the session is removed manually by the client the same things that happen in step 2 occur.
  4. If a client closes the browser and the session times out or is removed the login page appears when the client next tries to connect to QlikView. Closing the browser clears the cached credentials which is standard web browser behavior.

In previous dialog with QlikView, they’ve said this can’t be fixed because the authentication information is stored in the browser and there is no way the server can clear that information.  This is inaccurate because when a session is removed from the server, the requested object or page should not allow the credentials to be submitted to the server when the session value is null or does not match a current session on the server. This is done with a few simple If statements on the sever side code.  In the next paragraph, we’ve provided an example of the code required to fix this problem.  This code is for the front end (browser) and an example of what can be implemented server side to secure access.  We don’t have access to server side to make this change. 

if (($(c).find("value[name='Redirect']").attr("mode") == "enabled") && ($(c).find("value[name='Redirect']").attr("value") == "/qlikview/login.htm")) {

window.location.href = '/qlikview/login2.htm';

return;

  This issue has been well documented in the Qlikview forums, yet they continue to ignore the problem and frustrate their customers who are trying to secure sensitive corporate data.  We planned to submit this suggestion as an enhancement request on the QV site but Qlik.com does not have any area on their site to post suggestions or enhancement requests. We continue to bring this issue up, but it is inexcusable that QV has ignored a security vulnerability of this magnitude that can be easily fixed with a few lines of server side code.

7 Replies
Not applicable

Re: Continued Security Flaws! 3 years and counting!

Hi Larry! Which version of QlikView server do you have installed?

julian_rodrigue
Valued Contributor

Re: Continued Security Flaws! 3 years and counting!

I just want to know what QV have to say about this...

Not applicable

Re: Continued Security Flaws! 3 years and counting!

We are currently using 11.20 SR4. QlikView had us try SR5 and SR6 but we didn't see any security improvements in either of those that corrected the issues we stated so we stayed on SR4. I can't speak to any of the more current SR's.

Not applicable

Re: Continued Security Flaws! 3 years and counting!

We are continually being told this was going to be fixed but they are approaching this as if it really isn't a problem. They keep telling us they are working to get this resolved, and it hasn't been resolved for over three years!

Not applicable

Re: Continued Security Flaws! 3 years and counting!

Can I also ask which settings you have configured in the QMC under "QlikView Web Servers->Authentication->Type" and "QlikView Web Servers->Authentication->Login Address" for your setup?

If using the option "Default login page (browser authentication)" under "QlikView Web Servers->Authentication->Login Address" have you considered using web-form authentication instead?

Not applicable

Re: Continued Security Flaws! 3 years and counting!

Authentication = Always

Type = NTLM

Login Address = Default login page

we are currently using the QV web server we have tried to fix this with every possible setting change and by switching to IIS so please don't try to recommend just a setting change.

Not applicable

Re: Continued Security Flaws! 3 years and counting!

Just wanted to follow up here as I got a Customer reffering too this Thread.

I tried to check the Details of your issue but could not find any open Case. For me it sound like an issue with the Configuration as ou use the Default login page (browser authentication). This is the default setting as most customer like to use Single Sign On with their Active Directory. If you change to Alternate login page (web form) and the user ran into a timeout a WebPage will come up and you have to sign in again.

Community Browser