For security considerations, FineDataLink provides some security feature toggles on the Security tab page, including Cookie Enhancement, HSTS Setting, File Upload Verification, Forbid Script to Call Formula, Security Headers, Request Response Optimization, and Token Authentication Enhancement.
This document introduces the above security functions. You can enable them with one click on the Security tab page as needed, as shown in the following figure.
Cookie Enhancement is disabled by default. After you click this switch:
Cookie Enhancement can be enabled successfully if the current server protocol is detected as HTTPS.
If the current server protocol is detected as HTTP, a message will pop up, saying "This function cannot be enabled because the current server protocol is detected as HTTP. Verify that the server enables HTTPS and try again." and the function fails to be enabled, as shown in the following figure.
HTTP Strict Transport Security (HSTS) is an Internet security mechanism for the browser to automatically use HTTPS when accessing a website, ensuring that you always access encrypted links of websites for secure data transmission.
HSTS Setting is disabled by default. The function can be enabled only after HTTPS is enabled for the server, in which case HTTP access is forbidden. Browsers earlier than IE 11 do not support the setting currently.
If the current server protocol is detected as HTTP, a message will pop up upon a click on the button, saying "This function cannot be enabled because the current server protocol is detected as HTTP. Verify that the server enables HTTPS and try again.", as shown in the following figure.
After you enable HSTS Setting, the Strict-Transport-Security header (default value: max-age=31536000; includeSubdomains) is added.
The super admin can modify the header value through the FINE_CONF_ENTITY Visualization Configuration plugin.
WebSecurityConfig.hstsHeader
max-age=<expire-time>
max-age=31536000
All requests will be transformed into HTTPS ones to access a domain for 31536000 seconds after the browser receives the first HTTPS response.
max-age=<expire-time>; includeSubDomains
max-age=31536000; includeSubdomains
This setting also applies to all the subdomains of a website.
max-age=<expire-time>; preload
max-age=31536000; preload
Here, HSTS is enforced via the preload list.
File upload vulnerabilities occur when an attacker uploads an executable script file, which enables the attacker to execute commands on the server. Such vulnerabilities usually occur when the web server allows uploading images or text files so that attackers can bypass the upload mechanism to upload malicious code and execute it to control the server.
File Upload Verification is enabled by default. In this case, the system verifies the extension, size, and binary header of uploaded files during data entry, platform appearance configuration, and local file upload.After passing verification, files are uploaded, otherwise the upload fails.The following table describes how to configure the verification.
Solution One: Temporarily disable File Upload Verification and re-upload files.
Solution Two: Refer to the following section to modify the verification rules for the file type to allow uploading files of the required types.
File Size
The maximum size of an image that can be uploaded defaults 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 smaller than 1024 x 768 and a size not more than 20 MB in a format such as PNG and JPG.
You can set the file size limitation through file widgets. Files exceeding the size limitation cannot be uploaded.
In this case, a message will pop up, saying "The file is too large. The maximum file size is xxx KB."
File type
The whitelist (specifying the type of files that can be uploaded)includes:
JPG, JPEG, GIF, BMP, PNG, PDF, DOC, DOCX, PPT, PPTX, XLS, XLSX, and ZIP.
The blacklist (specifying the type of files that cannot be uploaded) includes:
ASP, JSP, PHP, and EXE.
Binary Header of Files
The system verifies the binary header of files to determine the file type and prevent the upload of files with extensions mismatched with the actual type to be uploaded.
Log in to FineDataLink as an admin, choose System Management > Security Management > Security, and enable File Upload Verification, as shown in the following figure.
The super admin can modify the file upload verification type through the FINE_CONF_ENTITY Visualization Configuration plugin.
WebSecurityConfig.fileInspectorType
0
Files with extensions not in the whitelist are allowed without verification.
Files with extensions in the whitelist are allowed only after headers are verified as matched with the actual file type.
1
(Default) Files with extensions in the whitelist and matched headers are allowed.
2
Files with extensions not in the blacklist are allowed without verification.
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.
A message is displayed when you upload a file in an unsupported format (for example, a ZIP file) under System Management > Appearance Configuration, indicating that the file failed to be uploaded because the file type is not supported, as shown in the following figure.
Assume that a non-PNG file renamed with a .png extension is uploaded.
In this case, the system verifies the binary header and finds that the uploaded file is actually a non-PNG file. 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 database operations such as creating, deleting, reading, and updating data. Their risk level is comparable to that of remote code execution.
Therefore, Forbid Script to Call Formula is added in FineDataLink. If the function is enabled, scripts are prevented from calling risky formulas.
Log in to the FineDataLink system as an 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 vulnerability exploitation.
Click Advanced Setting to display the five sub-features, 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)
Content Security Policy (CSP) is a security mechanism similar to a whitelist. By declaring approved sources in the policy, it informs browsers or clients of what is allowed to load and what is not.
Specifically, websites will send a CSP header to inform browsers of the above information. This means that even if attackers discover a vulnerability and attempt to inject malicious scripts, those scripts will fail to run because they are not from approved sources.
After Content Security Policy (CSP) is enabled, Content-Security-Policy:object-src 'self' is added to the request header by default, restricting plugin-based resources to be loaded only from the current domain.
Log in to the FineDataLink system as an admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. Content Security Policy (CSP) is enabled automatically, as shown in the following figure.
The super admin can modify the policy through the FINE_CONF_ENTITY Visualization Configuration plugin.
WebSecurityConfig.contentSecurityPolicyHeader
object-src
object-src 'self'
Content-Security-Policy: <policy-directive>; <policy-directive>
1. none indicates that no matching is performed.
2. self indicates that matching with the current origin (not its subdomain) is performed.
3. unsafe-inline indicates that inline JavaScript and CSS can be used.
4. unsafe-eval indicates that text-to-JavaScript mechanism like eval() can be used.
The source addresses of the tags (<object>, <embed>, and <applet>) are limited and can only be matched with the current source, rather than its subdomains.
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 resources (such as images, fonts, and scripts) only through HTTPS.
XSS is a type of web-based attack in which attackers exploit website vulnerabilities to inject malicious scripts. These scripts are mostly written in JavaScript, but can also include Java, Flash, or HTML.
After a successful attack, attackers can gain higher permission, access private sessions and sensitive data such as cookies, and so on.
After Prevent XSS Attack is enabled, X-XSS-Protection:1; mode=block is added to the request header by default. This activates the browser's XSS filter, which prevents the page from loading upon detecting an XSS attack.
Log in to the FineDataLink system as an admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. Prevent XSS Attack is enabled automatically, as shown in the following figure.
WebSecurityConfig.xssProtectionHeader
X-XSS-Protection: 0
The XSS filter is disabled.
X-XSS-Protection: 1
The XSS filter is enabled. The browser will sanitize the page by removing unsafe content upon detecting an XSS attack.
1; mode=block
X-XSS-Protection: 1; mode=block
The XSS filter is enabled. The browser will not sanitize the page, but will prevent the page from loading upon detecting an XSS attack.
1; report=<reporting-uri>
Example: 1; report=xss.php
X-XSS-Protection: 1; report=xss.php
The XSS filter is enabled.
The browser will clear the page and send a violation report to xss.php via CSP upon detecting an XSS attack.
Clickjacking is a visual deception technique that tricks users into interacting with hidden pages to perform risky operations.
Attack methods are as follows:
Attackers overlay a transparent iframe on a web page and trick users into operating on that web page. In this case, users will unknowingly click on the transparent iframe page.
Attackers cover the content in the original position on the web page with an image.
After Prevent Clickjacking is enabled, X-Frame-Options:SAMEORIGIN is added to the request header by default, preventing pages within the site from being embedded by other pages.
This response header is an identifier to instruct the browser 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, thereby avoiding clickjacking attacks.
Log in to the FineDataLink system as an admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. Prevent Clickjacking 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/).
Multipurpose Internet Mail Extensions (MIME) is a standard specifying the nature and format of documents, files, or byte streams.
In general, browsers determine resource types through the Content-Type field in the response header. If Content-Type of some resources is incorrect or undefined, some browsers will enable MIME-sniffing to infer resource types, parse the content, and execute it.
After Prevent Content Sniffing Attack is enabled, X-Content-Type-Options:nosniff is added to the request header by default to disable browser type inference to enhance security.
Log in to the FineDataLink system as an admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Settings. Prevent Content Sniffing Attack is enabled automatically, as shown in the following figure.
WebSecurityConfig.contentTypeOptionsHeader
nosniff
X-Content-Type-Options: nosniff
The following two types of requests will be blocked: Requests of the style type but non-text/css MIME type and requests 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 sign-on fails, press F12 to open the browser console. A cross-domain-related error message is displayed, as shown in the following figure. In this case, disable Prevent Content Sniffing Attack under Advanced Setting in the Security Headers area.
To disable browser cache, three IDs are involved:
The Cache-Control HTTP header field holds directives — in both requests and responses — that control caching in browsers and shared caches. These directives are unidirectional, which means that directives set in a request may not be included in the corresponding response.
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, meaning that the resource is already expired. If the Cache-Control response header includes a max-age or s-max-age directive, the Expires header will be ignored.
Pragma is a general HTTP/1.0 header whose effect depends on the specific implementation, and it may have varying effects along the request-response chain. This header is used for backward compatibility with the HTTP/1.0 caches, which existed before the Cache-Control header was introduced in HTTP/1.1.
After Disable Browser Cache is enabled, Cache-Control:no-cache, Pragma:no-cache, and Expires:0 are added to the request header by default.
Log in to the FineDataLink system as an admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting and enable Disable Browser Cache, as shown in the following figure.
The super admin can modify the specific policy through the FINE_CONF_ENTITY Visualization Configuration plugin.
WebSecurityConfig.cacheControlHeader
no-cache
Cache-control: no-cache
Before the cache copy is served, the cache server is required to revalidate the request with the origin server(conditional request for cache validation).
max-age=<seconds>
max-age=3600
Cache-control: max-age=3600
The maximum cache storage period (in seconds) is set, beyond which the cache is considered expired.
WebSecurityConfig.cacheControlExpiresHeader
Expires: <http-date>
The resource cached at a date in the past has already expired.
<http-date>
Wed, 21 Oct 2015 07:28:00 GMT
After 7:28 am (GMT) on Wednesday, October 21, 2015, the response has expired.
WebSecurityConfig.cacheControlPragmaHeader
Pragma: no-cache
Pragma: no-cache has the same effect as Cache-Control: no-cache. The cache server is required to revalidate the request with the origin server before returning the cache version.
Request Response Optimization is disabled by default. After Request Response Optimization is disabled, stack details are displayed.
If you think that displaying stack details poses a security risk, you can enable Request Response Optimization.
When Request Response Optimization is enabled, all stack traces will be replaced with simplified error messages: "Request error. Visit the Security Management page for detailed error information."
Log in to the FineDataLink system as an admin, choose System Management > Security Management > Security, and enable Request Response Optimization, as shown in the following figure.
For example, if you add an SQL dataset in the FineDataLink system and use a non-existent data table User, the preview will fail. You can click Details to view the reason for failure.
1. If Request Response Optimization is not enabled, 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 is displayed and error stack details are blocked after you click Details, as shown in the following figure.
1. Token is the unique identifier for a user.Token-based authentication follows the following logic:
The client requests initial login through a username and password.
After receiving the login request, the server retrieves and verifies the password corresponding to the username.
Upon successful verification, the server generates a user-bound token (unique identifier) based on user information and issues 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.
Upon receiving a request, the server verifies the token included in the client's request. If the verification succeeds, the server returns the requested data; if it fails, an error message is returned, prompting the client to log in again.
2. Token has the following security risks:
The issued token remains valid within the validity period, during which the server cannot forcibly invalidate it.
If attackers steal the token, they can send requests from other devices to impersonate the user to log in, which poses a security risk.
3. The IP address corresponding to the token can be verified to prevent the token from being hijacked or misused by attackers.
Token Authentication Enhancement is disabled by default.
The status server corresponding to the token stores the IP address from 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 of the current request matches that of the corresponding token, the request is automatically passed.
If not, the request is considered illegal, and the login page is automatically displayed for re-login.
Log in to the FineDataLink system as an 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" in a pop-up window.
After you click OK, the system login page is displayed for re-login, as shown in the following figure.
滑鼠選中內容，快速回饋問題
滑鼠選中存在疑惑的內容，即可快速回饋問題，我們將會跟進處理。
不再提示
10s後關閉
Submitted successfully
Network busy