Enable cross-site scripting protection

Secure > Enhance site security

Enable 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.

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 Pattern class 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 to disable the check in. For example, 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>
Alternately, you can block requests in Accelerator in 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>
If you have migrated from an earlier WebSphere Commerce, the 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>
The attributes are defined...
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.
IBM recommends to add the following regular expression to the 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.

Note: 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".
Start the WebSphere Commerce instance if it is not already started.

Run the following command:

WC_INSTALL/bin/config_ant.sh -DinstanceName=instance UpdateEAR

WC_INSTALL/bin/config_ant.bat -DinstanceName=instance UpdateEAR

Restart the WebSphere Commerce instance.
Results

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

+
Search Tips | Advanced Search