Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Qlik Connect 2026! Turn data into bold moves, April 13 -15: Learn More!
cancel
Showing results for 
Search instead for 
Did you mean: 
pljsoftware
Creator III
Creator III

QVD files store connection string in plain text!

Hi all!

I have noticed a very strange thing using QVD files... Inside the file, I can read in plain text my QlikView script, including the connection string with password!

How it can be possible?

66 Replies
flipside
Partner - Specialist II
Partner - Specialist II

I've just picked up this conversation (must have missed it because I rarely use QVD files), but have been looking at my qvw files in notepad.

In QV10 SR3, the NTNAMEs I have in my section access within the hidden script are exposed in the XML section footer which I am a little concerned about (especially as one of them is a service account!).  In all versions (9 and 10), I can see my variables within the encrypted sections, which could contain sensitive information.  SR3 actually makes it easier to see these variables because it adds them to the XML footer.

My questions are ...

1) Does SR4 hide/scramble all the XML footer? (I cannot get SR4 at the moment to test it and don't want to upgrade to QV11 just yet).

2) Are the variables still visible or is there a way to hide them (I cannot set them to Nothing in the script because they are needed for user interaction in the document and other stuff). Anyway some of them are system variables.

flipside

rbecher
MVP
MVP

This sounds very serious!

I'm not so familiar with section access but I would presume then that somebody also could hack security credentials in the QVW file directly?

OMG

Data & AI Engineer at Orionbelt.ai - a GenAI Semantic Layer Venture, Inventor of Astrato Engine
flipside
Partner - Specialist II
Partner - Specialist II

Well thankfully, just changing the NTNAME to grant document security bypass hasn't worked ... phew!! The file becomes corrupted it appears.

rbecher
MVP
MVP

With QVDViewer2 you can quickly show the stored lineage info from your QVD:

http://twitpic.com/7t7td8

Could be faster for bigger QVD files than open with a file editor.

- Ralf

Data & AI Engineer at Orionbelt.ai - a GenAI Semantic Layer Venture, Inventor of Astrato Engine
pljsoftware
Creator III
Creator III
Author

Excellent application Ralf.

I have try it with a QVD of 50MB, stored by QV 10 SR3, and I found my ODBC connection string with password in plain.

Now I want to try with SECTION ACCESS, if we have plain text there it's a disaster.

Regards

Luca Jonathan Panetta

PLJ Software

johnw
Champion III
Champion III

Just written to our head of security as part of our ongoing conversation on this problem (with a few details omitted to allow for public consumption):

"I'm not sure why I didn't realize this before – of course even the published QVWs have this information in the header.  Unlike the source QVWs and QVDs, access to which is fairly restricted, the published QVWs are sometimes open to everyone in the company.  We typically do database access only to create QVDs, so the published QVWs wouldn’t have the account and password in them.  But there are exceptions, and I just found one such exception in a QVW that is published to our entire company...

So our entire company has access to the account we're using for most of our QlikView ODBC access.  Fortunately... payroll... uses a different account...  But it wouldn't surprise me if some file is exposing that to the entire company or to many more people than intended (like me).

If it were me, I’d probably shut QlikView down until this is fixed.  But perhaps security holes this serious are frequent, and if we shut down affected software every time, we’d never be able to run the business."

Anonymous
Not applicable

John, Do you use the Accesspoint with plugin? 

We have researched this issue with our Security people also.   It has definitely turned some heads.  But based on all our "End Users" accessing the  Accesspoint through QV Server, they dont have access to the QVW's or QVD's from that view.   If they were computer savy enough, they could Explore to the Accesspoint and open them up with notepad.  But they still must have access rights to the file.  I would think we are covered from an external person gaining the passwords, but we are still working through the scenarios of internal users.   

Does anyone have a situation that would make that false????

Is it confirmed that SR4 cures this issue?

Thanks,

JS

Not applicable

Is this still a risk if document download is disabled ?

johnw
Champion III
Champion III

Our users use Accesspoint with the IE plugin, yes. 

So far as I know, Publisher is using the distribution information you give it to control access to the file itself in the file system.  So for the file I mentioned, I can see in the file properties, security tab, "Authenticated Users".  For a more restricted file, I see the specific AD group that is granted access to the file.

So once you're logged in to our network, you can grab the passwords.  An external person could only get the passwords if they logged in to our network.  So yes, it seems safe enough from anyone external to our company.

And in practice, our users don't know there's a security hole to exploit, don't know how to get at these files through the file system, and even if they got the account, they don't know our databases, which are all using very cryptic table and field names, so they would have a very hard time figuring anything out.

But ugh.

johnw
Champion III
Champion III

Juan Fibonacci wrote:

Is this still a risk if document download is disabled ?


For US, yes.  Our users are already logged in to our network, and have DIRECT access to the file through our file system without downloading it.  They don't know where it is, but there's nothing in the security setup itself that I'm aware of that prevents them from finding the file and opening it in notepad. 

I suspect that if someone was NOT logged in to your network, and could ONLY get the underlying file by download, then disabling download would keep them from hacking the password.  But I'm not certain how all that works.