This article explains the concept of Cross site scripting and how to enable it for the QlikView management console (QMC).
Starting with QlikView 12.30 (November 2018) the feature is now enabled by default.
Environment:
QlikView
Short explanation
- Ajax client creates the request and adds a cookie called "CSRF_TOKEN" and the attribute value called "csrf" that have the same value
- Ajax sends the request to QMS
- QMS validates if the two values are equal
- If they are equal QMS executes the request
- If they are NOT equal QMS stops the execution, displays pop-up for the user saying that the invalid request parameter has been detected and adds the information to the QMS logs (IP address of the invalid token sender).
What is CSRF?
"Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user’s Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful cross-site request forgery attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context. In effect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed." (OWASP definition)
Recommended mitigation technique
Double submit cookies.
Double submit cookies is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value are equal. When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way. The site should then require every sensitive submission to include this random value as a hidden form value (or other request parameter) and also as a cookie value. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the random CSRF value.
Requirements:
- For each request to the QMC a unique CSRF token shall be created by client side code.
- The CSRF token shall be created using a cryptographic pseudo-random number generator (CPRNG) in all browsers versions supporting the RandomSource.getRandomValues() function (https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues).
- The CSRF token shall be of 120 bits entropy strength (15 ASCII character string) .
- The CSRF token shall be transported in BASE64 encoding format to avoid HTTP/URL character encoding problems.
- The CSRF token shall have the “Secure” flag enabled if the connection is established through HTTPS.
- The CSRF token value shall be submitted to the QMC, in 2 parts of the client request:
1 In client request header as cookie.
In client request data (POST) part
- The CSRF token shall NOT be sent in the client request URL as URL argument.
- For each client request received by the QMC, the server side code shall verify that the CSRF token value provided in client request header and client request data (POST) part are equal. If CSRF token values differ then request shall be rejected and incident shall be logged in the QMS event log. If CSRF token values are equal then client request can be accepted and processed by the QMS code.
Implementation (Web Client part)
The method for creating the token uses a native crypto object where available to produce 15 randomized ASCII characters between 33 and 126. (Weaker randomization is used for IE10 and below). The resulting string is then base64-encrypted before it's added to the request body and the cookie respectively. The cookie is flagged secure on https connections. The unique token is created for every request sent to QMS.
Implementation (Server Components part)
First of all, the whole mechanism is put under a switch called EnableCrossSiteRequestForgeryProtection. It can be found in QMS configuration file (C:\Program Files\QlikView\Management Service\QVManagementService.exe.config). If it's not manually changed the default value will be false which means that the server will not perform the check (the client will still create the cookie and the attribute value, meaning that the client part is always executed). If the config value is set to true, the server will compare the two values for every POST request. If the values are the same the server will continue to execute the request. If the two values are not the same the server will stop the execution and print the message to the user in a pop-up in QMC (the message will be "Invalid request parameter. Please refer to the QMS logs for more information.").
- Open C:\Program Files\QlikView\Management Service\QVManagementService.exe.config in a text editor launched with administrator permissions
- Change* <add key="EnableCrossSiteRequestForgeryProtection" value="false"/> to true
- Save file and restart QlikView Management Service for changes to take effect.
To disable the setting, change the value back to false.
* Should the key not be present in 12.30 or higher, insert it manually. Make sure to restart the QMS after saving the file.
