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. We 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. We can turn cross site scripting on or off at the module level only.

Note:

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, we 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 to disable the check in. For example, to disable the check in WebSphere Commerce Accelerator requests, make the following changes marked in bold:

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, we can block requests in WebSphere Commerce Accelerator on a per command basis. We 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

  1. Open the WebSphere Commerce configuration file.

  2. 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 our production environment 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 environment 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: IBM recommends 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>

    For the REST API, the command name will be the relative URL path of the REST service. For example:

      <Command display="false" name="/store/{storeId}/cart/copy_order" >
      <Attribute display="false" ...
      <Attribute display="false" ...
      </Command>

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


Related reference
Tag: out
JSP programming best practice: Use the escapeXml attribute to preserve HTML formatting