Overview
Version
Report Server Version | Functional Change |
11.0 | / |
11.0.12 | Added the Referer validation function. After this function is enabled, visitor access is controlled based on the whitelist content. |
11.0.14 | Changed the error content prompted after Request Response Optimization is enabled. |
11.0.18 | Optimized configuration items of the Referer validation, allowing users to determine that if the Referer field is empty or does not exist in the request, users are not allowed to access the resource. |
11.0.19 | Added the URL configuration item through which users are allowed to use/not to use semicolons in the URL. |
Functions
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.
Cookie Enhancement
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.
Cookie Enhancement fails to be enabled and 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." is displayed in a pop-up prompt box if the current server protocol is detected as HTTP.
HSTS Settings
Functions
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 HTTPS is enabled for the server, in which case HTTP access is forbidden. Currently, this setting is not supported by browsers of versions earlier than IE 11.
After you click this switch, 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." is displayed in a pop-up prompt box if the current server protocol is detected as HTTP, as shown in the following figure.
Note:
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.
Note:Configuration Item | Configuration Value | Configuration Example | Explanation |
WebSecurity Config.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 | All requests will be transformed into HTTPS ones to access this domain name within 31536000 seconds after the browser receives the first HTTPS request. This rule also applies to all subdomain names of the website. | |
max-age=<expire-time>; preload | max-age=31536000; preload | All requests will be transformed into HTTPS ones to access this domain name within 31536000 seconds after the browser receives the first HTTPS request. In this case, HSTS is preloaded. |
File Upload Verification
Function Description
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 uploaded files during filling, platform appearance configuration, and local file upload. After successful verification, files are uploaded. If verification fails, file upload fails. The following table describes how to specifically configure verification.
Note:If files fail to be uploaded due to verification failure, you can re-upload files successfully through one of the following solutions:
Solution One: Temporarily disable the File Upload Verification switch and re-upload files.
Solution Two: Modify the file verification type by referring to the following section so that files of this type can be uploaded.
Verification Content | Specific Setting |
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 smaller 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 through File Widget. Files exceeding the size limitation cannot be uploaded. In this case, a message "The file is too large. The maximum file size is xxx KB." is displayed in a pop-up box. | |
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. |
Setting Method
Log in to the decision-making platform as the admin, choose System Management > Security Management > Security, and enable File Upload Verification.
Super admin can modify the file upload verification type through the FINE_CONF_ENTITY Visual Configuration plugin.
Note:Configuration Item | Value | Rule |
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. |
Effect Example
Example Template: %FR_HOME%\webroot\WEB-INF\reportlets\demo\Resume.cpt
Open the template in FineReport Designer and click the cell with the file widget.
Modify the file type in the file widget to PDF and set the file size limitation to 10 KB in the right-hand Attribute tab page.
File Size Verification
Click Data Entry Preview to open the preview page, upload a file larger than 10 KB, and a message "The file is too large. The maximum file size is 10 KB." is displayed in a pop-up prompt box. The file upload fails.
File Type Verification
Click Data Entry Preview to open the preview page, upload a file not in PDF format, and a message "Upload is disallowed. Formats of files allowed to be uploaded include: pdf" is displayed in a pop-up prompt box. The file upload fails.
Verifying File's Binary Header
Assume that a file with a non-PDF extension changed to one with a PDF extension is uploaded.
In this case, the system verifies the binary header and finds that the uploaded file is actually one with a non-PDF extension. Then a message "It is a file type prohibited from being uploaded, and files that are allowed to be uploaded include pdf." is displayed in a pop-up prompt box. The file upload fails.
Forbidding Scripts to Call Formulas
Function Description
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.
Therefore, the Forbid Script to Call Formula switch is added in FineReport. If this switch is enabled, scripts are prevented from calling risky formulas.
Note:Setting Method
Log in to the decision-making platform as the admin, choose System Management > Security Management > Security, and enable Forbid Script to Call Formula.
Effect Example
Enable the Forbid Script to Call Formula switch. If you use the FR.remoteEvaluate and FR.remoteEvaluateAsync interfaces, a message "This call poses security risks. If you need to call it, modify Forbid Script to Call Formula in Security Management." is displayed in a pop-up prompt box during preview.
1. Choose File > New General Report in FineReport Designer and enter Test in cell B1.
Click Hyperlink on the right to add JavaScript code to the cell, as shown in the following figure.
2. Select Pagination Preview, click Test, and a prompt box pops up with the following message, as shown in the figure below.
Security Headers
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.
Note:After Security Headers is enabled, all sub-switches are enabled by default.
After Security Headers is disabled, all sub-switches are disabled by default and advanced protection functions cannot be enabled.
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)
CSP Content Security Policy
Function Description
Content Security Policy (CSP), similar to a configured whitelist, informs browsers or clients of what is authorized to execute and what is prohibited.
Specifically, 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 CSP Content Security Policy is enabled, the Content-Security-Policy:object-src 'self' setting is added to the request header by default, allowing all external resources to be loaded only from the current domain.
Setting Method
Log in to the decision-making platform as the admin, choose System Management > Security Management > Security, and enable Security Headers.
Click Advanced Setting. The CSP Content Security Policy switch is enabled automatically.
Super admin can modify the specific policy through the FINE_CONF_ENTITY Visual Configuration plugin.
Note:Configuration Item | Configuration Value | Configuration Example | Syntax | Explanation |
WebSecurityConfig.contentSecurityPolicyHeader | object-src | object-src 'self' |
Note:(1) none indicates that no matching is performed. (2) self indicates that matching with the current origin (not its subdomain) is performed. | The system restricts the source address of <object>, <embed>, <applet> tags and only allows matching with the current origin (not its subdomain). |
object-src | object-src https://example.com/ |
| ||
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. |
XSS Attack Protection
Function Description
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, the X-XSS-Protection:1; mode=block setting is added to the request header by default. After the XSS filter is enabled, the browser will stop loading the page upon detecting XSS attack.
Note:Setting Method
Log in to the decision-making platform as the admin, choose System Management > Security Management > Security, and enable Security Headers.
Click Advanced Setting. The XSS Attack Protection switch is enabled automatically.
Super admin can modify the specific policy through the FINE_CONF_ENTITY Visual Configuration plugin.
Note:Configuration Item | Configuration Value | Syntax | Explanation |
WebSecurityConfig.xssProtectionHeader | 0 | X-XSS-Protection: 0 | The system prohibits XSS filtering. |
1 | X-XSS-Protection: 1 |
The browser will clear the page and remove the unsafe parts upon detecting XSS attack. | |
1; mode=block | X-XSS-Protection: 1; mode=block |
The browser will not clear the page, but prevent page loading upon detecting XSS attack. | |
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 attack. |
Clickjacking Prevention
Function Description
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.
Attackers cover the content in the original web page position by an image.
After Click Attack Protection is enabled, the X-Frame-Options:SAMEORIGIN setting is added to the request header by default, 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.
Setting Method
Log in to the decision-making platform as the admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. The Click Attack Protection switch is enabled automatically.
Super admin can modify the policy of X-Frame-Options through the FINE_CONF_ENTITY Visual Configuration plugin.
Note:Configuration Item | Configuration Value | Syntax | Explanation |
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/). |
Notes
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.
Content Sniffing Attack Prevention
Function Description
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. If 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, the X-Content-Type-Options:nosniff setting is added to the request header by default to disable browser type guessing for higher security.
Setting Method
Log in to the decision-making platform as the admin, choose System Management > Security Management > Security, and enable Security Headers. Click Advanced Setting. The Prevent Content Sniffing Attack switch is enabled automatically.
Super admin can modify the policy of X-Content-Type-Options through the FINE_CONF_ENTITY Visual Configuration plugin.
Note:Configuration Item | Configuration Value | Syntax | Explanation |
WebSecurityConfig.contentTypeOptionsHeader8 | nosniff | X-Content-Type-Options: nosniff |
(2) Request of the script type but non-JavaScript MIME type. |
Notes
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, as shown in the following figure. In this case, disable Prevent Content Sniffing Attack under Advanced Setting in the Security Headers area.
Disabling Browser Cache
Function Description
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 may 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, the Cache-Control:no-cache and Pragma:no-cache&Expires:0 settings are added to the request header by default.
Setting Method
Log in to the decision-making platform as the admin, choose System Management > Security Management > Security, and enable Security Headers.
Click Advanced Setting. The Disable Browser Cache switch is enabled automatically.
Super admin can modify the specific policy through the FINE_CONF_ENTITY Visual Configuration plugin.
Note:Configuration Item | Configuration Value | Configuration Example | Syntax | Explanation |
WebSecurityConfig.cacheControlHeader Note: | no-cache | 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 Note: | 0 | 0 | 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 Note: | no-cache | no-cache | Pragma: no-cache |
|
Request Response Optimization
Function Description
The Request Response Optimization switch is enabled by default in projects of 11.0.14 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.
Setting Method
Log in to the decision-making platform as the admin, choose System Management > Security Management > Security, and enable Request Response Optimization.
Effect Example
For example, after you add an SQL dataset in the decision-making platform 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 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, for example, 11300001 Dataset configuration error [SQLITE_ERROR] SQL error or missing database (no such table: User), is displayed after you click Details.
Note:1. If you want to view error stack details, simply disable the Request Response Optimization switch.
2. After Request Response Optimization is enabled in projects of versions earlier than 11.0.14, the message "Request error. If you want to view detailed error information, disable Request Response Optimization on the Security Management page." is displayed, hiding all stack information.
Token Authentication Enhancement
Function Description
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 by attackers.
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 of the current request and that of the corresponding token are consistent, the request is automatically passed.
If not, the request is considered illegal and the login page is automatically displayed for re-login.
Setting Method
Log in to the decision-making platform as the admin, choose System Management > Security Management > Security, and enable Token Authentication Enhancement.
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 box.
After you click OK, the system login page is displayed for re-login.
Referer Validation
Note: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 illegal theft of server resources.
After you enable Referer validation and configure whitelists in FineReport, visitor identities will be recognized and filtered based on the whitelists, preventing reports in the project from being directly accessed or accessed through links from other websites.
Setting Method
Super admin can modify the specific strategy of Referer validation through the following configuration items.
Note:Configuration Item | Configuration Value | Definition/Rule |
WebSecurityConfig.refererVerifyEnabled | true | Referer validation is enabled. |
false | (Default) Referer validation is disabled. | |
WebSecurityConfig.refererWhiteList | Format: ["item1","item2"] Example: ["http://localhost:8075","localhost:8075","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 | true | If the Referer field is empty or does not exist in the request, users are allowed to access the current resource. |
false | If the Referer field is empty or does not exist in the request, users are not allowed to access the current resource. Note: |
Effect Example
Click to download the template: Modifying the Referer Validation Configuration Item.cpt
Modify the configuration item of Referer validation in fine_conf_entity as required.
Note:Enabling Referer Validation
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. Choose Server > Platform Management in the menu bar in FineReport Designer, and the project access fails.
3. Press F12 or right-click to select 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. In this case, 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. In this case, the request is successful and a status code 200 is returned, as shown in the following figure.
Enabling Referer Validation and Configuring a Whitelist
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 localhost domain to access resources.
Click Submit. After the project is restarted, the configuration item takes effect, as shown in the following figure.
2. Choose Server > Platform Management in the menu bar in FineReport Designer, and the project access is successful.
3. Press F12 or right-click to select 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:8075/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.
Notes
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.
URL Semicolon Filtering Mechanism
Function Description
If Tomcat parses the requested URL (containing a semicolon) of a user, Tomcat will filter out the string content (including the semicolon) between the semicolon and the slash and normalize it.
Attackers can bypass the permission verification mechanism by using semicolons to access sensitive resources or perform malicious operations, posing a security risk to system.
URL configuration items are added in FineReport of 11.0.19 and later versions to forbid the use of semicolons in URLs, preventing security issues such as path traversal attacks, permission bypass, URL obfuscation, and deception.
Setting Method
Super admin can determine whether semicolons are allowed in URLs through the following configuration items.
Note:Configuration Item | Configuration Value | Definition/Rule |
WebSecurityConfig.allowURLSemicolon | true/No configured parameter value (default) | Semicolon can be used in the URL. |
false | Semicolon cannot be used in the URL. |
Effect Example
Semicolon Allowed in URL
When the WebSecurityConfig.allowURLSemicolon parameter is not configured or the parameter value is true, semicolon can be used as a separator in the URL.
For example, if the URL with a semicolon (like http://localhost:8075/webroot/decision/;12345/login) is accessed through the browser, Tomcat will filter out the string content (including the semicolon), such as ;12345/, between the semicolon and the slash and normalize it.
The actual URL is http://localhost:8075/webroot/decision/login, and the project can be accessed normally, as shown in the following figure.
Setting Parameter Value to false
1. Add the WebSecurityConfig.allowURLSemicolon field in the fine_conf_entity table in the project, and set the parameter value to false.
After the project is restarted, the configuration takes effect and semicolon cannot be used in the URL.
2. In this case, if the URL with a semicolon (http://localhost:8075/webroot/decision/;12345/login) is accessed through the browser, request error occurs and the project cannot be accessed.
