Enabling cross-site scripting protection

When enabled, cross-site scripting protection rejects any user requests that contain attributes (parameters) or strings that are designated as not allowable. You can also exclude commands from cross-site scripting protection by allowing the values of specified attributes for that particular command to contain prohibited strings. Cross-site scripting protection is enabled by default.

Attention: Cross site scripting is defined globally, not at the web module level. You can turn cross site scripting on or off at the module level only.

About this task

Note:

This feature can help to reject malicious requests from executing. In addition, all JSP files must follow JSP programming best practice: Use the escapeXml attribute to preserve HTML formatting to output encode special characters:
For example, if you are using the <c:out> tag when outputting URL parameters or attributes, encode it using the following syntax.
```
<c:out value="${param1}"/>
```
By default, this JSTL tag escapes the following five special XML characters to prevent them from being used as part of a malicious string:
```
<
                                > 
                                &
                                '
                                "
```
Another tag that has even more escaping options is the <wcf:out> tag. For a detailed description of the tag and information about using it, see Tag: out.
If XSiteScriptingProtection/enabled is true in wc-server.xml, then the following syntax could be used to escape Javascript special characters:
```
<wcf:out value="${localeValue}" escape="true" escapeFormat="js" />
                        
```
This would escape the following characters:
```
<
                                > 
                                &
                                '
                                "
                                \
                                \n
                                \r
                                \t
                                \f
```
The <wcf:out> tag can also integrate with OWASP ESAPI libraries to enable other types of encoding.
In addition to the recommendations on using JSTL to escape input on JSP files, you might need to take additional steps to sanitize input on JSP files, depending on how your implementation is coded. You must follow the OWASP XSS guidelines for additional protection documentation.
Cross-Site scripting protection is enhanced to use regular expression which are not case-sensitive. The regular expression syntax is based on the standard used by Java. For the regular expression syntax, see Sun's Class Pattern Java API documentation.

Attention: Cross-site scripting protection is a restrictive feature in that it will restrict the execution of commands based on its configuration. The feature does not check what attributes or strings have been defined as prohibited. Therefore, when configuring it, ensure that the prohibited attributes are not those used by the commands and that the prohibited strings are not values that are commonly passed to the commands. Use extreme caution when configuring this feature.

Cross-site scripting protection can be disabled at the Web module level. For example, you can explicitly disable the cross-site scripting check box in WebSphere Commerce Accelerator, while enabling it in stores. Only the Stores Web Module have the Cross Site Scripting Protection feature enabled by default.

To configure cross-site scripting protection, open wc-server.xml and search for the Web module that you want to disable the check in. For example, if you want to disable the check in WebSphere Commerce Accelerator requests, make the following changes marked in bold:

<Module contextPath="/webapp/wcs/tools" fileServletEnabled="false"
		name="CommerceAccelerator" urlMappingPath="/servlet" webAlias="/wcs">
		<InitParameters adapters="BrowserAdapter"
			contextSetName="Authoring" />
		<URLRedirectFilter enable="true" />
		<XSiteScriptingProtection enable="false" />
	</Module>

Note: If you perform cross-site scripting checks against WebSphere Commerce encrypted values such as the krypto URL parameter or the WC_AUTHENTICATION cookie, the following Base64 encoded non-alphanumeric characters are used in these ciphers; '+', '/', '=', and the line feed character ('%0A' URL encoded).

Alternately, you can block requests in WebSphere Commerce Accelerator on a per command basis. You can determine all commands in WebSphere Commerce Accelerator open this file: WC_install/xml/policies/xml/defaultAccessControlPolicies.xml see all commands that can be accessed by the Seller role. The Seller role is WebSphere Commerce Accelerator superuser. Commands that can be accessed by the Seller role are defined in the "SellersCmdResourceGroup".

Procedure

Open the WebSphere Commerce configuration file.

Edit the following block:


<XSiteScriptingProtection
      enabled="true" name="Cross Site Scripting Protection">

      <ProhibitedAttrs display="false">
         <Attribute display="false"  name="parameter1" />
         <Attribute display="false"  name="parameter2" />
         <Attribute display="false"  regex=".*/&lt;script.*/" />
      </ProhibitedAttrs>

      <ProhibitedChars display="false">
         <Character display="false" name="&lt;SCRIPT"/>
         <Character display="false" name="&lt;%"/>
         <Character display="false" name="&amp;lt;%"/>
         <Character display="false" name="&amp;lt;SCRIPT"/>
         <Character display="false" regex=".*javascript.*"/>                    
      </ProhibitedChars>

      <ProhibCharEncoding display="false">
         <Command display="false" name="Command1">
                  <Attribute display="false" name="parameter3" />
            </Command>

          <Command display="false" name="Command2">
                  <Attribute display="false" name="parameter4" />
            </Command>
      </ProhibCharEncoding>
</XSiteScriptingProtection>

Note: If you have migrated from an earlier WebSphere Commerce, your XSiteScriptingProtection block might have attribute values encoded as HTML entities. As an example, the following is equivalent to the ProhibitedChars element above:


      <ProhibitedChars display="false">
         <Character display="&amp;#102;&amp;#97;&amp;#108;&amp;#115;&amp;#101;"
                    name="&amp;#60;&amp;#83;&amp;#67;&amp;#82;&amp;#73;&amp;#80;&amp;#84;" />
         <Character display="&amp;#102;&amp;#97;&amp;#108;&amp;#115;&amp;#101;"
                    name="&amp;#60;&amp;#37;" />
         <Character display="&amp;#102;&amp;#97;&amp;#108;&amp;#115;&amp;#101;"
                    name="&amp;#38;&amp;#108;&amp;#116;&amp;#59;&amp;#37;" />
         <Character display="&amp;#102;&amp;#97;&amp;#108;&amp;#115;&amp;#101;"
                    name="&amp;#38;&amp;#108;&amp;#116;&amp;#59;&amp;#83;&amp;#67;&amp;#82;&amp;#73;&amp;#80;&amp;#84;" />  
      </ProhibitedChars>

Here are some recommended additions to the ProhibitedCharacters element of the Cross-Site Scripting configuration for your production server configuration file:

<Character display="false" regex=".*((%(25)+)|%)*((3C)|&lt;)[\s]*+img.*"/>
<Character display="false" regex=".*((%(25)+)|%)*((3C)|&lt;)[\s]*+iframe.*"/>
<Character display="false" regex=".*\x00.*"/>
<Character regex=".*(((%(25)+)|%)+(3C))|&lt;|&amp;lt.*" />
<Character regex=".*&amp;#((0)*60|x(0)*3c).*" />
<Character regex=".*\\(u|x)0*3c.*" />

Note: Some of these entries might be too restrictive for the authoring server when using tools like Management Center.

where:

XSiteScriptingProtection.enabled

Specifies whether cross-site scripting protection is enabled. Possible values are true (the default) or false.

XSiteScriptingProtection.ProhibitedAttrs.Attribute.name

The name of command attributes (parameter) that are not allowed. The values are case-sensitive and must match exactly.

Example:


<ProhibitedAttrs display="false">
        <Attribute display="false"  name="parameter1" />
        <Attribute display="false"  name="parameter2" />
</ProhibitedAttrs>

This definition will block the following request because it has an attribute named parameter1:

XYZCommand?storeId=10001&parameter1=27&catalogId=10051

The following requests will be allowed because their attribute names do not exactly match any of the restricted attributes:

XYZCommand?storeId=10001&parameter10=27&catalogId=10051
XYZCommand?storeId=10001&Parameter2=27&catalogId=10051

XSiteScriptingProtection.ProhibitedAttrs.Attribute.regex

Attribute names that matches to this regular expression are not allowed. The values are not case-sensitive.

Note: It is recommended to add the following regular expression to your configuration to prevent cross- site scripting attacks:


<Attribute display="false"  regex="./&lt;script.*" />

Example:


<ProhibitedAttrs display="false">
        <Attribute display="false"  regex="./&lt;script.*" />
</ProhibitedAttrs>

This definition will block the following request because it matches the regular expression ./<script./:

XYZCommand?storeId=10001&>.<ScrIpt123=27&catalogId=10051

The following request will be allowed because their attribute names do not match the configured regular expression:

XYZCommand?storeId=10001&>.script111=27&catalogId=10051

XSiteScriptingProtection.ProhibitedChars.Character.name:

Prohibited strings that should not be used anywhere in the request name or in the attribute values. The prohibited string is not case-sensitive and will also block larger strings that contain the specified string.

The following strings are specified by default. These strings are most commonly used as scripting tags in malicious cross- site scripting attacks :

<ProhibitedChars display="false"> 
  <Character display="false" name="<SCRIPT"/> 
  <Character display="false" name="<%"/> 
  <Character display="false" name="&amp;lt;%"/> 
  <Character display="false" name="&amp;lt;SCRIPT"/> 
  <Character display="false" name="javascript"/> 
  <Character display="false" name="&#xa;&#xd;"/> 
  <Character display="false" name="&amp;#x6a;&amp;#x61;&amp;#x76;&amp;#x61;&amp;#x73;&amp;#x63;&amp;#x72;&amp;#x69;&amp;#x70;&amp;#x74;"/> 
  <Character display="false" name="&amp;#106;&amp;#97;&amp;#118;&amp;#97;&amp;#115;&amp;#99;&amp;#114;&amp;#105;&amp;#112;&amp;#116;"/> 
  <Character display="false" regex=".*((%(25)+)|%)*((3C)|<)[\s]*+script.*"/> 
</ProhibitedChars>

XSiteScriptingProtection.ProhibitedChars.Character.regex:

Regular expressions of prohibited strings that should not be used anywhere in the request name or in the attribute values. The regular expression prohibited string is not case-sensitive.

Example:


<ProhibitedChars display="false">
        <Character display="false" regex="./javascript./"/>
</ProhibitedChars>

This definition will block the following request:


Request	Reason
`XYZCommand?storeId=abcjavascript123&storeId=101`	Matches the regular expression `./javascript./` in one of the attribute values.

XSiteScriptingProtection.ProhibCharEncoding.Command.name:

The name of a command (action path; defined in Struts configuration files) to exclude from cross site scripting protection by allowing the value of its specified parameter to contain prohibited strings. The name of the corresponding parameter is specified in the XSiteScriptingProtection.ProhibCharEncoding.Command.Attribute.name attribute.

Example:


<ProhibCharEncoding display="false">
        <Command display="false" name="Command1">
               <Attribute display="false" name="parameter3" />
        </Command>
         <Command display="false" name="Command2">
               <Attribute display="false" name="parameter4" />
         </Command>
</ProhibCharEncoding>

This definition will approve the following request:


Request	Reason
`Command1?parameter3=<scripting`	Although "<script" is typically a prohibited string, Command1 and parameter3 have been specified as an exception pair in the ProhibCharEncoding element.

As expected, the following request will still be rejected:


Request	Reason
`Command2?parameter3=<script`	Command2 and parameter3 have not been specified as an exception pair in the ProhibCharEncoding element; therefore, parameter3 is not allowed to contain the prohibited string "<script".

Note: The action type is not limited to BaseAction (Controller commands, or views). The action type can also be (Ajax)RESTAction, or (Ajax)ComponentServiceAction. For example, the following sample excludes the AddressUpdate Controller command, AddressBookForm view, and the AjaxRESTPersonChangeServiceAddressAdd REST service call from being filtered.

<ProhibCharEncoding display="false">
<Command display="false" name="AddressUpdate"><Attribute display="false" name="address1"/></Command>
<Command display="false" name="AddressBookForm"><Attribute display="false" name="address1"/></Command>
<Command display="false" name="AjaxRESTPersonChangeServiceAddressAdd"><Attribute display="false" name="address1"/></Command>
</ProhibCharEncoding>

Start your WebSphere Commerce instance if it is not already started.
Run the following command:
- WC_installdir/bin/config_ant.sh -DinstanceName=instance_name UpdateEAR
- WC_installdir/bin/config_ant.bat -DinstanceName=instance_name UpdateEAR
Restart your WebSphere Commerce instance.

Note: When a cross-site scripting violation has been detected, the request is changed to go to the ProhibCharEncodingErrorView view.