6.0
/
6.0.7
Added the Referer validation function. After this function is enabled, visitor access is controlled based on the whitelist content.
6.0.11
Changed the error content prompted after enabling request response optimization.
For security considerations, the platform provides some security function-related switches on the Security tab page, including Cookie Enhancement, HSTS Settings, File Upload Verification, Forbid Script to Call Formula, Security Headers, Request Response Optimization, and Token Authentication Enhancement.
This document explains the above security functions. You can enable protection measures with one click on the Security tab page as required, as shown in the following figure.
The Cookie Enhancement switch is disabled by default. After you click this switch:
Cookie enhancement can be enabled normally if the current server protocol is detected as HTTPS.
The message "This function cannot be enabled because the current server protocol is detected as HTTP. Verify that the server enables HTTPS and try again." pops up if the current server protocol is detected as HTTP, as shown in the following figure.
HTTP Strict Transport Security (HSTS) is an Internet security mechanism for the browser to automatically access the website address, ensuring that users always access encrypted links of websites for secure data transmission.
The HSTS Settings switch is disabled by default. The switch can be enabled only after the server has enabled HTTPS, in which case HTTP access will be prohibited. Currently, this setting is not supported by browsers of versions later than IE 11.
Setting Method
After you enable HSTS Settings, the Strict-Transport-Security header (default value: max-age=31536000; includeSubdomains) is added.
Super admin can modify the header value through the FINE_CONF_ENTITY Visual Configuration plugin.
WebSecurityConfig.hstsHeader
max-age=<expire-time>
max-age=31536000
All requests will be transformed into HTTPS ones to access this domain name within 31536000 seconds after the browser receives the first HTTPS request.
max-age=<expire-time>; includeSubDomains
max-age=31536000; includeSubdomains
This rule also applies to all subdomain names of the website.
max-age=<expire-time>; preload
max-age=31536000; preload
In this case, HSTS is preloaded.
File upload vulnerabilities occur when attackers upload an executable script file and obtain the ability to run server-side commands through this script file. Such vulnerabilities generally take place when the web server allows users to upload images or ordinary text files so that attackers can bypass the upload mechanism to upload malicious code and execute it to control the server.
The File Upload Verification switch is enabled by default. In this case, the system verifies the extension, size, and binary header of filling files, platform appearance configuration files, and locally uploaded files. After successful verification, files are uploaded. If verification fails, file upload fails. The following table describes how to specifically configure verification.
If files fail to be uploaded due to verification failure, you can re-upload files successfully through one of the following solutions:
Solution 1: Temporarily disable the File Upload Verification switch and re-upload files.
Solution 2: Modify the file verification type by referring to the following section so that files of this type can be uploaded.
File size
Set the size of an image that can be uploaded to be less than or equal to 20 MB under System Management > Appearance Configuration to prevent the program from hanging.
If an image exceeding the size limitation is uploaded, a dialog box is displayed, prompting you to select an image with a resolution not less than 1024 x 768 and a size not more than 20 MB in format such as PNG and JPG.
You can manually set the file size limitation by the file control. Files exceeding the size limitation cannot be uploaded.
In this case, a message is displayed, indicating that the file is too large, exceeding the size limitation of xxx KB.
File type
Configure a whitelist (specifying the type of files that can be uploaded) to include the following:
JPG, JPEG, GIF, BMP, PNG, PDF, DOC, DOCX, PPT, PPTX, XLS, XLSX, and ZIP.
Configure a blacklist (specifying the type of files that cannot be uploaded) to include the following:
ASP, JSP, PHP, and EXE.
Binary header of files
Determine the file type by verifying the binary header of files, and forbid files with extensions mismatched with the actual type to be uploaded.
Log in to the FineBI system as admin, choose System Management > Security Management > Security, and enable File Upload Verification, as shown in the following figure.
Super admin can modify the file upload verification type through the FINE_CONF_ENTITY Visual Configuration plugin.
WebSecurityConfig.fileInspectorType
0
Files with extensions not in the whitelist are directly passed.
Files with extensions in the whitelist can be passed only after headers are verified as matched.
1
(Default) Files with extensions in the whitelist and matched headers are passed.
2
Files with extensions not in the blacklist are directly passed.
A message is displayed when you upload an image larger than 20 MB under System Management > Appearance Configuration, indicating that the file failed to be uploaded because the file is too large, as shown in the following figure.
Choose Public Data and select a folder with management permissions. Choose Add Dataset > Excel Dataset and add an Excel dataset.
If you upload a malformed file, such as a .zip file, the message "Only files in CSV, XLS, or XLSX format can be uploaded. Re-upload a correct one." is displayed, as shown in the following figure.
Assume that a file with a non-XLSX extension changed to one with a XLSX extension is uploaded.
In this case, the system verifies the binary header and finds that the uploaded file is actually one with a non-XLSX extension. Then the message "Upload failed because the file extension does not match the actual one." is displayed, as shown in the following figure.
The FR.remoteEvaluate and FR.remoteEvaluateAsync interfaces frequently used in JS pose high security risks, possibly allowing attackers to implement operations such as database adding, deletion, modification, and query. Their risk level is equivalent to that of remote execution.
So the Forbid Script to Call Formula switch is added in FineBI. If this switch is enabled, scripts are prevented from calling risky formulas.
Log in to the FineBI system as admin, choose System Management > Security Management > Security, and enable Forbid Script to Call Formula, as shown in the following figure.
If Security Headers is enabled, the HTTP Security Headers attribute is attached to the request header, preventing vulnerabilities.
Click Advanced Setting to display the five sub-switches, as shown in the following figure.
The following describes the specific settings of sub-switches enabled by default.
res.addHeader("X-Content-Type-Options", "nosniff");res.addHeader("X-XSS-Protection", "1; mode=block");res.addHeader("X-Frame-Options", "SAMEORIGIN");res.addHeader("Content-Security-Policy","object-src 'self'");res.addHeader("Cache-Control", "no-cache");res.addHeader("Pragma", "no-cache");res.addDateHeader("Expires", 0)
res.addHeader("X-Content-Type-Options",
"nosniff"
);res.addHeader(
"X-XSS-Protection"
,
"1; mode=block"
"X-Frame-Options"
"SAMEORIGIN"
"Content-Security-Policy"
"object-src 'self'"
"Cache-Control"
"no-cache"
"Pragma"
);res.addDateHeader(
"Expires"
, 0)
Content Security Policy (CSP), similar to a configured whitelist, informs browsers or clients of what is authorized to execute and what is prohibited.
As such, websites will send a CSP header to inform browsers of above information. In this way, even attackers discovering vulnerabilities write attack scripts, no such attack is successful because attack scripts are not in the whitelist.
After Content Security Policy (CSP) is enabled, Content-Security-Policy: object-src 'self is added to the request header by default for setting, allowing all external resources to be loaded only from the current domain.
Log in to the FineBI system as admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. The CSP Content Security Policy switch is enabled automatically, as shown in the following figure.
Super admin can modify the policy through the FINE_CONF_ENTITY Visual Configuration plugin.
WebSecurityConfig.contentSecurityPolicyHeader
object-src
object-src 'self'
Content-Security-Policy: <policy-directive>; <policy-directive>
The system restricts the source address of <object>, <embed>, <applet> tags and only allows matching with the current origin (not its subdomain).
object-src uri
The system restricts the source address of <object>, <embed>, <applet> tags and allows loading only from https://example.com/ in the above tags.
default-src
default-src https:
The system disables unsafe inline/dynamic execution and allows loading these resources (such as images, fonts, and scripts) only through HTTPS.
Cross-Site Scripting (XSS) is a type of security vulnerability on websites enabling attackers to write attack programs, such as JS programs (common ones), Java programs, Flash programs, and HTML programs. After successful attack, attackers can achieve higher permissions, private sessions, and cookies.
After XSS Attack Protection is enabled, X-XSS-Protection:1; mode=block is added to the request header by default for setting. After the XSS filter is enabled, the browser will stop loading the page upon detecting XSS.
Log in to the FineBI system as admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. The XSS Attack Protection switch is enabled automatically, as shown in the following figure.
WebSecurityConfig.xssProtectionHeader
X-XSS-Protection: 0
The system prohibits XSS filtering.
X-XSS-Protection: 1
The system enables XSS filtering. The browser will clear the page and remove the unsafe parts upon detecting XSS.
1; mode=block
X-XSS-Protection: 1; mode=block
The system enables XSS filtering. The browser will not clear the page, but prevent page loading upon detecting XSS.
1; report=<reporting-uri>
Example: 1; report=xss.php
X-XSS-Protection: 1; report=xss.php
The system enables XSS filtering.
The browser will clear the page and send a violation report using the CSP xss.php function upon detecting XSS.
Clickjacking is a visual deception technique that tricks users into interacting with hidden pages to perform risky operations.
Attack methods are as follows:
Attackers superimpose a transparent iframe on a web page and trick users to operate on that web page. In this case, users will unknowingly click on the transparent iframe page.
For example, attackers cover the content in the original web page position by an image.
After Click Attack Protection is enabled, X-Frame-Options:SAMEORIGIN is added to the request header for setting, preventing in-site pages from being embedded in other pages.
This response header is an identifier to inform the browser of whether a page can be displayed in <frame>, <iframe>, <embed>, or <object>. Sites can use this function to prevent the website from being embedded in attackers' sites, avoiding clickjacking.
Log in to the FineBI system as admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. The Click Attack Protection switch is enabled automatically, as shown in the following figure.
WebSecurityConfig.frameOptionsHeader
deny
X-Frame-Options: deny
The browser will refuse to load any frames on the current page.
sameorigin
X-Frame-Options: sameorigin
This page can be displayed in frames on a page with the same domain name.
allow-from uri
Example: allow-from https://example.com/
X-Frame-Options: allow-from https://example.com/
This page can be displayed in frames from the specified origin (https://example.com/).
After Click Attack Protection is enabled, pages can only be loaded within the same domain by default.
You possibly cannot access reports embedded through cross-domain iframe in this case, as shown in the following figure. To resolve this, simply disable Click Attack Protection under Advanced Setting in the Security Headers area.
Multipurpose Internet Mail Extensions (MIME) is a standard specifying the nature and format of documents, files, or bytes.
In general, browsers distinguish resource types through the Content-Type field in the response header. When some resources have incorrect or undefined Content-Type, some browsers will enable MIME-sniffing to guess resource types, parse the content, and execute it.
After Prevent Content Sniffing Attack is enabled, X-Content-Type-Options:nosniff is added in the request header for setting by default to disable browser type guessing for higher security.
Log in to the FineBI system as admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. The Prevent Content Sniffing Attack switch is enabled automatically, as shown in the following figure.
WebSecurityConfig.contentTypeOptionsHeader8
nosniff
X-Content-Type-Options: nosniff
The following two types of requests will be blocked: (1) Request of the style type but non-text/css MIME type. (2) Request of the script type but non-JavaScript MIME type.
After Prevent Content Sniffing Attack is enabled, resources of mismatched MIME types cannot be shared across domains.
If single-site login fails, open the console in the browser by pressing F12. A cross-domain-related error message is displayed. In this case, disable Prevent Content Sniffing Attack under Advanced Setting in the Security Headers area, as shown in the following figure.
To disable browser cache, three IDs are involved:
The Cache-Control HTTP header field holds unidirectional directives — in both requests and responses — that control caching in browsers and shared caches. That is to say, directives set in requests many not be included in responses.
The Expires HTTP header contains the date/time after which the response is considered expired. Invalid expiration dates with value 0 represent a date in the past and mean that the resource is already expired. If there is a Cache-Control header with the max-age or s-max-age directive in the response, the Expires header is ignored.
The Pragma HTTP/1.0 general header is an implementation-specific header that may have various effects along the request-response chain. This header serves for backwards compatibility with the HTTP/1.0 caches that do not have a Cache-Control HTTP/1.1 header.
After Disable Browser Cache is enabled, Cache-Control:no-cache, Pragma:no-cache, and Expires:0 is added to the request header by default for setting.
Log in to the FineBI system as admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. The Disable Browser Cache switch is enabled automatically, as shown in the following figure.
Super admin can modify the specific policy through the FINE_CONF_ENTITY Visual Configuration plugin.
Definition
WebSecurityConfig.cacheControlHeader
no-cache
Cache-control: no-cache
Before the cache copy is published, the cache server is forced to submit the request to the original server for validation (cache negotiation validation).
max-age=<seconds>
max-age=3600
Cache-control: max-age=3600
The maximum cache storage period (in seconds) is set, beyond which cache is considered expired.
WebSecurityConfig.cacheControlExpiresHeader
Expires: <http-date>
The resource cached at a date in the past is already expired.
<http-date>
Wed, 21 Oct 2015 07:28:00 GMT
After 7:28 am (GMT) on Wednesday, October 21, 2015, the response is expired.
WebSecurityConfig.cacheControlPragmaHeader
Pragma: no-cache
no-cache has the same effect as Cache-Control. The cache server is forced to submit the request to the original server for validation before returning the cache version.
The Request Response Optimization switch is enabled by default for projects of 6.0.11 and later versions.
After Request Response Optimization is disabled, stack details are displayed. If you think that displaying stack details poses a security risk, you can enable the Request Response Optimization switch.
In this case, key error information is displayed without error stack details.
Log in to the FineBI system as admin, choose System Management > Security Management > Security, and enable Request Response Optimization, as shown in the following figure.
For example, after you add an SQL dataset in the FineBI system and use a non-existent data table User, the preview fails. You can click Details to view the preview failure cause.
(1) If Request Response Optimization is disabled, error stack details are displayed after you click Details, as shown in the following figure.
(2) If Request Response Optimization is enabled, only key error information, for example, 11300001 Dataset configuration error SQL error or missing database (no such table: User), is displayed after you click Details.
(1) Token is the unique user identifier. Token-based authentication follows the following logics:
The client requests initial login through a username and password.
After receiving the login request, the server queries and verifies the password corresponding to the username.
After successful verification, the server generates a user-bound token (unique identifier) based on user information and sends it to the client.
The client stores the received token locally and needs to request resources from the server each time with the server-issued token carried.
The server returns requested data to the client if the client-sent request is verified as token carrying, and returns an error message if the verification failed (requiring the client to log in again in this case).
(2) Token has the following security risks:
The issued token remains valid within the validity period, in which the server cannot force the token to expire.
Attackers stealing the token (if any) can send requests on other machines to impersonate the user to log in, posing a security risk.
(3) The IP address corresponding to the token can be verified to prevent the token from being hijacked or misused.
The Token Authentication Enhancement switch is disabled by default.
The status server corresponding to the token stores the IP address corresponding to the first login request.
After Token Authentication Enhancement is enabled, the server verifies the token and the corresponding IP address upon receiving a request.
If the IP address and token of the current request are consistent, the request will be automatically passed.
If not, the request is considered illegal and the login page is automatically displayed for re-login.
Log in to the FineBI system as admin, choose System Management > Security Management > Security, and enable Token Authentication Enhancement, as shown in the following figure.
After Token Authentication Enhancement is enabled, if the IP address of the request changes, the system will display the message "Re-log in as login information has expired", as shown in the following figure. After clicking OK, you will be redirected to the system login page. In this case, log in again.
Function Description
The Referer field in the HTTP request header contains the HTTP request source, that is, from which webpage users enter the current page.
Access control rules (such as whitelists) set based on the Referer field on the server side allow users to access server resources only through fixed web pages, preventing server resource theft.
After you enable Referer validation and configure whitelists in FineBI, visitor identities will be recognized and filtered based on the whitelists, preventing dashboards in the project from being directly accessed or accessed through links from other websites.
Super admin can modify the specific strategy of Referer validation through the following configuration items.
WebSecurityConfig.refererVerifyEnabled
true
Referer validation is enabled.
false
Referer validation is disabled (by default).
WebSecurityConfig.refererWhiteList
Format: ["item1","item2"]
Example: ["http://localhost:37799","localhost:37799","localhost"]
The field value should be the configured whitelist content, and Referer lists should be separated by commas.
Only domain names in whitelists can access the current resource.
WebSecurityConfig.refererAllowEmpty
If the Referer field is empty or does not exist in the request, users are allowed to access the current resource.
Click to download template FineDB Field Modification.cpt.
Modify the configuration item of Referer verification in fine_conf_entity as required.
(1) Add the WebSecurityConfig.refererVerifyEnabled field to the fine_conf_entity table in the project and set its value to true.
Click Submit. After the project is restarted, the configuration item takes effect and Referer validation is enabled, as shown in the following figure.
(2) Enter the project address http://IP address:Port number/webroot/decision in the browser to access the FineBI system. The access fails, as shown in the following figure.
(3) Press F12 or right-click to choose Inspect to open Chrome console, switch to the Network tab page, and check the status code and Referer field of the request.
View requests with the Referer field. Because no whitelist is configured, the whitelist content is empty, preventing all domain names from accessing the current resource. As such, the request is abnormal and 403 status code is returned, as shown in the following figure.
View requests without the Referer field. Because WebSecurityConfig.refererAllowEmpty is fixed to true, allowing requests with empty Referer or without Referer to access the current resource. As such, the request is successful and a status code 200 is returned, as shown in the following figure.
For example, enable Referer validation and set the whitelist to ["localhost"].
(1) Perform the following operations in the fine_conf_entity table of the project.
Add the WebSecurityConfig.refererVerifyEnabled field, set its value to true, and enable Referer validation.
Add the WebSecurityConfig.refererWhiteList field and set its value to ['localhost'], allowing requests from the domain localhost to access resources.
Click Submit. After the project is restarted, the configuration item takes effect, as shown in the following figure.
(2) Enter the project address http://IP address:Port number/webroot/decision in the browser to access the FineBI system. The access is successful, as shown in the following figure.
(3) Press F12 or right-click to choose Inspect to open Chrome console, switch to the Network tab page, and check requests with the Referer field.
For example, for the Referer: http://localhost:37799/webroot/decision request, the domain name is localhost, which is in the whitelist and allowed to access the current resource, as shown in the following figure.
If you have configured CAS single-site login, both the project URL and CAS URL need to be added to the whitelist. Otherwise login will fail.
If you have configured cross-domain single-site login, both URLs of the cross-domain projects need to be added to the whitelist. Otherwise login will fail, as shown in the following figure.
滑鼠選中內容，快速回饋問題
滑鼠選中存在疑惑的內容，即可快速回饋問題，我們將會跟進處理。
不再提示
10s後關閉
Submitted successfully
Network busy