Configure to enable protection against cross-site scripting (XSS) attacks

Feedback

To solve cross-site scripting (XSS) vulnerability issues such as URL link injection, DOM-based XSS, URL wide-character and URL cross-site vulnerabilities, you can modify the iServer configuration file [SuperMap iServer installation directory] \webapps\iserver\WEB-INF\web.xml to enable protection against XSS attacks.

Configure to start protection against XSS attacks as follows:

<filter> 
      <filter-name>XssFilter</filter-name>
      <display-name>XssFilter</display-name>
      <filter-class>com.supermap.server.host.webapp.XssFilter</filter-class>
      <init-param>
            <param-name>processMode</param-name>
            <!-- Optional value：CLEAN or THROWERROR. CLEAN clears dangerous characters; THROWERROR throws exceptions -->
            <param-value>CLEAN</param-value>
      </init-param>
      <init-param>
            <param-name>antisamyName</param-name>
            <!-- Optional value：antisamy-myspace.xml, antisamy-ebay.xml, antisamy-tinymce.xml or antisamy-slashdot.xml -->
            <param-value>antisamy-ebay.xml</param-value>
      </init-param>
</filter>
<filter-mapping>
      <filter-name>XssFilter</filter-name>
      <url-pattern>/*</url-pattern>
</filter-mapping>

Note:

When multiple web filters exist at the same time, the loading and implementation of each web filter has a strict order relationship. It is consistent with the definition order of each web filter in the web.xml file. In order to make XSSFilter work, you need to define FilterMappping for the Filter in web.xml.
After the web.xml configuration is completed, restart the iServer (iPortal) to take effect.

Among them, the main configuration parameters are as follows:

processMode. Default value：CLEAN. Optional value：CLEAN, THROWERROR
1. CLEAN：Remove unsafe characters
2. THROWERROR：Report errors directly in response

antisamyName: the security policy document. The default value is antisamy-ebay.xml. Optional value：antisamy-myspace.xml, antisamy-ebay.xml, antisamy-tinymce.xml, antisamy-slashdot.xml.
1. antisamy-myspace.xml：comparatively dangerous, suitable for social networking sites and allow the user input as a whole page
2. antisamy-ebay.xml：comparatively safe, filtering content, suitable for e-commerce websites and allow users to enter HTML scripts as part of the page
3. antisamy-tinymce.xml：comparatively safe and only allows text formats to pass through
4. antisamy-slashdot.xml：comments filtering for news sites

Parameter name: xsrfDefendEnable (protection against cross-site request forgery), default value: false, is off.
Parameter name: xsrfDefendTime, default value is null, time unit is ms. When the protection against cross-site request forgery is enabled, the protection against cross-site request interval will take effect only when the interval is set to greater than zero. Cross-site requests to the same resource on the iServer (iPortal) within the set interval will be rejected.
Parameter name: refererWhiteList, default value is empty. The whitelist will take effect after the protection against cross-site request forgery is enabled. The default value of cross-site request whitelist is empty, at this time all cross-domain requests will be rejected. Users can add domain names (multiple domain names are separated by “;”) to the cross-site request whitelist through the configuration file. When the browser sends a request to iServer (iPortal), only the domain name (referer field in the request) of the request is in the whitelist, the user can access iServer (iPortal), and the request with domain name not in the whitelist will be rejected.
Parameter name: hostWhiteList (host request header whitelist), default value is empty. The host request header whitelist will be effective only after the protection against cross-site request forgery is enabled. host request header whitelist is empty, all host headers will be rejected at this time. Users can add host addresses (in the form of ip:port, multiple IP ports are separated by “;”) to the host request header whitelist through the configuration file. When the browser sends a request to iServer (iPortal), only the host request header of the request is in the whitelist, the user can access iServer (iPortal), and the request which host request header is not in the whitelist will be rejected.