Skip to content
CA Service Management - 14.1
Documentation powered by DocOps

Secure CA SDM from Cross-Site Scripting Vulnerabilities

Last update April 26, 2017

The CA SDM installation is susceptible to reflected cross-site scripting vulnerabilities, which might result in the infected URL being reflected back to the user. To secure CA SDM from such vulnerabilities, validation parameters exist in the web.cfg file. These parameters perform a white list validation in the webengine. Also, install the NX option on the primary and secondary servers to secure CA SDM.

Points to consider before you proceed with securing CA SDM:

  • The SDM URL parameters that are defined in the web.cfg file are validated for securing CA SDM.
  • You can add SDM URL parameters in the web.cfg file with required validation pattern. You can also add validation patterns, if necessary.

Secure CA SDM from Cross-Site Scripting Vulnerabilities in Conventional and Advanced Availability Mode

Follow these steps:

  1. Stop the CA SDM services.
  2. On the primary server, execute the following command to install the NX option.

    pdm_options_mgr -c -a pdm_option.inst -s VALIDATE_REQUEST_PARAMETER -v 1

    Note: For each secondary server, manually add or update the NX option in the NX.env file that is located in $NX_ROOT directory.

  3. (Optional) To avoid losing the changes when you run the pdm_configure command with the -t flag.

    pdm_options_mgr -c -a pdm_option.inst -s VALIDATE_REQUEST_PARAMETER -v 1 -t

  4. Restart the CA SDM services.
  5. (Optional) In Advanced Availability mode, perform rolling maintenance to apply the NX option on all servers.

How to Map a Parameter to an Existing White List Pattern

When you identify a parameter to be vulnerable, in the web.cfg file, you can map the parameter to a white list pattern against which the parameter is validated. For example, CONTACT_ID is the parameter that is vulnerable and you want to map the AlphaNumericOnly white list pattern to the parameter, which means the CONTACT_ID parameter can accept only alphanumeric characters. 

Follow the steps:

  1. Edit the web.cfg file, and in the XSS Vulnerability section, add the parameter that you want to validate against a pattern in the following way:

    SecureParameter.CONTACT_ID AlphaNumericOnly

  2. Edit the web.cfg.tpl file and update the same parameter.
  3. Restart the CA SDM services.

How to Create a White List Pattern

Apart from the out-of-the-box patterns, you can add or edit existing patterns to the web.cfg file.

Edit an Existing Pattern

For example, edit the following pattern to add colon as the allowable character: AlphaNumericOnly ^[A-Za-z0-9]*$ to AlphaNumericOnly ^[A-Za-z0-9:]*$


Edit the web.cfg file, locate Patterns for Non-Windows section and add the allowable character in the following way:

Non_windows_SecureValidator.AlphaNumericColonOnly ^[A-Za-z0-9:]*$


Edit the web.cfg file, locate Patterns for Windows section and add the allowable character in the following way:

Windows_SecureValidator.AlphaNumericColonOnly ^[A-Za-z0-9:]*$

After you add the patterns in the web.cfg file, perform the following steps:

  1. Edit the web.cfg.tpl file and update the same pattern.
  2. Restart the CA SDM services.
Was this helpful?

Please log in to post comments.

  1. J.W.
    2016-11-15 06:28

    Can CA provide examples of adding new validation patterns? Are these regex?

  2. Raghu Rudraraju
    2016-11-15 09:24

    Hi JW,

    Several samples are present in the web.cfg files in NX_ROOT/bopcfg/www folder.

    Yes, they are regex patterns. There's a validation pattern and a rule too.

    Example pattern: Windows_SecureValidator.NumberOnly ^[0-9]*$

    Example validation rule: SecureParameter.KEEP.ISPOPUP NumberOnly

    Hope this helps _R

    1. Rajashree Nair
      2016-11-15 11:35

      Thanks, Raghu Rudraraju for the helpful tips. Hi, J.W. please let us know, if in case, you need more information.

  3. Karen Matoke
    2017-04-04 07:03

    Also see technical document TEC1853292

    1. Rajashree Nair
      2017-04-06 06:33

      Karen Matoke, thanks for the feedback. 



      DocOps Services Team