Skip to main content

App Development

Discussion board where members can learn more about Qlik Sense App Development and Usage.

Announcements
Welcome to Qlik Community! Check out our new navigation! FIND OUT MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
thilo-rls
Contributor
Contributor

TRACE is executing code

Hello all,
I wonder if this is a feature, a bug, or a wide-open-security-issue ...

By accident I noticed that this command is producing a script error:

let a = 'nonsense_1;nonsense_2;';
TRACE $(a);

I stumbled when I noticed that my script is stopping with an 'Unknown statement: nonsense_2' error.
Why statement? TRACE is supposed to add text to the output/ log ... not executing statements.

I got curious ... so I created an Excel file with some code in it;
I am loading the code and TRACE it => it is really executed!

thilorls_0-1634915931295.png

 

thilorls_1-1634916236231.png

 

thilorls_2-1634916302892.png

 

While I still wonder if there is some value in it beyond experimental use (imagine to dynamically create a script-text in code based on loaded data and then TRACE it to force execution), I also am a bit worried if this is a potential (though very special) security issue (reminds me a bit on SQL-injection).

Maybe someone has related experience and real use cases for this?

PS: My environment is in German, but I think the screenshots are nevertheless clear enough.

4 Replies
Lauri
Specialist
Specialist

I would call it a bug. Qlik Help says: "The trace statement writes a string to the Script Execution Progress window and to the script log file..." To me, that sounds like it *shouldn't* be executed.

On the other hand, when I put multiple statements separated by ";" into the load editor, the highlighting tells me that the Trace applies only to the first statement.

Lauri_0-1634926201204.png

Qlik should update the Help to clarify that Trace applies to everything up to the first semi-colon.

And users should beware!

thilo-rls
Contributor
Contributor
Author

Hello Lauri,
now I see it ... your sample makes it obvious!
Of course it it is not the TRACE that is the 'issue', it's the $-expansion as such.
In this case I would call it a feature since it really allows to write dynamic code (this time in Qview):

thilorls_1-1635165815711.png

 

thilorls_0-1635165801864.png

(and yes, table cmd was successfully dropped)

As such it works a bit like writing commands to a txt file which is $included at a later point in script.

Anyways: in combination with TRACE I still think there is a tiny security issue (=> comparable to SQL injection), but at least now I understand the workings. Thank you!

marcus_sommer
MVP & Luminary
MVP & Luminary

I just did a test with QV 11.2 and QV 12.3 and the $-sign expansion with executing the content didn't happens within a trace-statement.

But of course the $-sign expansion is executed within the normal script. IMO that's ok. and a sensible feature which provides the possibility to create (load) statements on-the-fly. It's quite similar to the more native include-variables - only it's more dynamic.

Therefore I wouldn't think that's a special security risk. Of course there might be scenarios in which it might be abused. But by the "normal" usage of Qlik there should be no problem because no external user could execute a reload respectively a reload with external parameter/variables. In regard to internal users you need much more and other measures to ensure that there is none misuse of any rights / data.

Beside this there are usually not so many sensible possibilities to apply such logic. Just because that you could put everything into variables with or without parameters and even to nest them - it's mostly much more expensive to do it in this way instead of applying (maybe boring looking) standard script. Especially from a maintaining point of view I could only suggest - for you and others - keep it as simple as possible. 

I don't know if it's an unwanted behaviour if the $-sign variables are now within a trace-statement executed or if it was an intentionally change (maybe it's not documented yet) but it would make things easier. Personally I don't like the efforts to create extra variables to get a calculated result within a trace and therefore I outsourced the task into a sub-routine which checks the parameter, creates the necessary variables, makes - if needed - the calculations, returned the results and dropped the variables again ...

- Marcus

hic
Employee
Employee

This is expected behaviour - and the only logical behaviour.

Just as a couple of the above comments point at, it has to do with the dollar expansion, and not with the 'Trace'. You would in fact get the same problem if you put the $-expansion after some other keyword like a 'Let' or a 'Load'.

This is how it works: The $-expansion is a macro expansion that replaces text in the code before the script is parsed for execution. This means that before the script is parsed, the $(...) is replaced by the content of the variable. So, in this example, the parser would see

Let a = 'nonsense_1;nonsense_2;';
Trace nonsense_1;nonsense_2;;

which of course will lead to that the 'Trace' statement contains only 'nonsense_1', followed by an incorrect statement 'nonsense_2'.

The work-around is simple: Just quote your string in the Trace statement:

Let a = 'nonsense_1;nonsense_2;';
Trace '$(a)';

Then the parser will see

Let a = 'nonsense_1;nonsense_2;';
Trace 'nonsense_1;nonsense_2;';

HIC