Security rules on data connections can easily be circumvented

Okay, there are a few restrictions on this exploit, but nevertheless exploitable in a situation where:

Access to data connections have been restricted by security rules

The exploiter can publish an app that has an existing reload task running

How? Well, the reload task is not running as the owner of the app, or the task, but as INTERNAL\sa_scheduler.

All you need to do is:

LOAD *
FROM [lib://HiddenDataConnection/file.qvd] (options);

And wait for the task to run, then duplicate the app to you work folder.

Counterargument

One may argue that the name of the data connection is hidden, and so is the data structure inside the data connection (especially if it is a folder).

However, that is not security. And folder structure and name of data connections is not really secret information.

In may real-life case, we had developers in separate bank branches, that were not allowed to see each others data. But, of course they had the same data structure. Also, the plan was to name the data connections as 'Bank_A', 'Bank_B', etc. So guessing the name of another data connection was trivial.

If you have a similar setting, you may need to take extra precautions, until Qlik acknowledges this as s security vulnerability.

Not sure what the best fix would be. One suggestion is to let the task run as the owner of the task, of course, and not with system wide privileges.

Re: Security rules on data connections can easily be circumvented

this is a known behavior and there is currently no technical way to circumvent that.

I passed a pen-test in a bank in the past with that "bug" by doing this:

- perform a manual go-live check for every app, ensure that it only uses allowed connections (simple search in the script, your naming convention for data connections should make that easy)- only after that promote to the separated PROD-environment

For DEV in banking environments you and the developers anyway only have fake data. At least for me that was the case.

Re: Security rules on data connections can easily be circumvented

In my case we were not dealing with developers, but bank analysts. And they cannot use fake data, unfortunately.

One of our counter measures was to actively monitor the log files.

We cannot stop then from getting hold of a restricted data connection.But we stop them from getting hold of a restricted data connection, unnoticed.

When you try accessing a data connection that has been restricted from you, you will get an error when running the LOAD script, as it then, is running with your user privileges. So it has to be a deliberate act trying to circumvent a restriction put in place. Bringing on consequences for a full time permanent employee.

So in my case, with the type of data in question, the group of people, and other circumstances, we found an acceptable solution. But far from ideal.

My intention by publishing this, is to warn other people in the same situation. And hoping that someone other than my Qlik Support representative and his/her contact with R&D find this unacceptable, and prioritizing a proper solution.

Re: Security rules on data connections can easily be circumvented

Hi again,I think the main question is how you setup your roles and permissions in the organization.

Analysts in your case obviously have permissions to create apps and reload them. That works fine and secure with only the data connections they have access to since these are run with the respecitve user permissions.

The issue only surfaces when they also have access to the QMC and are allowed to setup reloads there. These are run with the sa_scheduler.

Basically you need to separate QMC access, so only Ops people are allowed to setup scheduled reloads. Then you don't have to scare people with consequences.

Re: Security rules on data connections can easily be circumvented

Its a security flaw, a big one. Qlik Sense is mainly designed as Self-Service platform yet that should not mean there would be no way to isolate individual projects objects (unless you had completely isolated environments), limiting users privileges (i.e. not being able to refresh data ) would not help either. What we have been told is that there are to be two modes - the existing one and the one that enforces better security which is always the option when confidential/sensitive data are being used. The switch is to be available in QMC and might not be available in previous releases since it would require DB changes.