Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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?
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
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
Well thankfully, just changing the NTNAME to grant document security bypass hasn't worked ... phew!! The file becomes corrupted it appears.
With QVDViewer2 you can quickly show the stored lineage info from your QVD:
Could be faster for bigger QVD files than open with a file editor.
- Ralf
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
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."
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
Is this still a risk if document download is disabled ?
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.
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.