Using the Message Threat Policy

Learn about using the Message Threat Policy to guard against XML-based denial of service attacks.

For information about using policies in the context of the Community Manager developer portal, see Business Policies.

Table of Contents

About the Message Threat policy

The Message Threat Policy is used to guard against XML-based denial of service attacks. An attacker can construct XML messages in such a way that parsing them could result in overwhelming CPU and/or memory consumption. This policy can detect such situations and reject the messages immediately.

Configure the policy by specifying acceptable parameters that will support your usual and expected traffic while protecting your system from attackers.

Creating a Message Threat policy

The first step in creating a policy is to define the basic policy information.

To add an operational policy

  1. Go to Workbench > Browse > Organization, and select Policies > Operational Policies. The Policies Summary is displayed.
  2. Click Add Policy.
  3. Choose the policy type and click Next.
  4. Specify a name (required) and description (optional) and click Finish. At the Completion Summary, click Close. The Add Policy Wizard creates a draft policy instance that you can then configure on the Policy Details page.

For more information, see Add Policy.

Configuring a Message Threat policy

Once you've created the policy, you can configure the policy options.

To configure a Message Threat policy

  1. Go to Workbench > Browse > Organization and select the Policies > Operational Policies folder. The Policies Summary is displayed.
  2. Find the policy on the list and click to go to the pane for the Message Threat policy.
  3. In the second section, click Modify. The Modify Message Threat Policy page opens, as shown below.

  4. Specify values for the policy as needed. For information on the individual options, see Message Threat Policy Options below.
  5. Save the policy definition.

That completes the policy configuration. You can now assign the policy to a service.

Message Threat policy options

The Modify Message Threat Policy wizard has one page, Specify Message Threat Policy Options. It includes the options listed below.

Maximum Nested Element Depth Allowed
Maximum amount of nesting levels that the Message Threat Policy allows in messages.
In the absence of this optional sub-assertion, services are not protected against a denial of service attack through too many nested elements.
Maximum Attributes Per Element
Maximum number of attributes allowed per element in messages.
In the absence of this optional sub-assertion, services are not protected against a denial of service attack through too many nested elements. An attacker could nest XML elements to the depth of thousands, which would clog the memory and slow the processor.
Maximum Size of a Document Node
Maximum number of kilobytes that a single node in the XML DOM tree can use.
In the absence of this optional sub-assertion, services are not protected against a denial of service attack through excessive node size. An attacker could overload an XML node with a huge amount of data.
Maximum Number of Name Space Prefixes
Maximum number of namespace prefixes allowed in the message.
In the absence of this optional sub-assertion, services are not protected against a denial of service attack through having a very large number of namespace prefixes, meaning that an attacker could include hundreds or thousands of namespaces in a single XML message.
Maximum Number of Name Space Definitions
Maximum number of namespace definitions allowed per message.
In the absence of this optional sub-assertion, services are not protected against a denial of service attack through having an excessive number of namespace definitions, meaning that an attacker could overload an XML message with a huge number of namespace definitions.
Maximum Entity Size Definable in DTD
If a DTD is present (internal or external) and there are entities defined, this value limits the maximum size (number of chars) of any given entity.
In the absence of this optional sub-assertion, services are not protected against a denial of service attack through DTD entity size that is too large, meaning that an attacker could overload an internal or external DTD entity with huge value in terms of number characters.
Maximum Number of Entities That Could Be Defined
If a DTD is present (internal or external) and there are entities defined, the maximum number of entities allowed per message.
In the absence of this optional sub-assertion, services are not protected against a denial of service attack through having an excessive number of entities, meaning that an attacker could overload a message with a huge number of entities (millions).
Maximum Recursive Depth of an Entity Definition
If a DTD is present (internal or external) and there are entities defined, the maximum depth allowed recursively.
In the absence of this optional sub-assertion, services are not protected against a denial of service attack through too great a recursive depth of entities, meaning that an attacker could employ huge number of entities recursively defined with value of other entities. This could cause combinatorial explosion of entities.

Activating a policy

When you create and configure a policy, the policy is in Draft state. When the policy configuration is complete, activate the policy: click Activate Policy and then confirm. See Activate a Policy.

A policy in Draft state is not available for general use. Once you activate the policy, it is in Active state and is available for use.

Attaching a policy

To use the policy, go to the Policies folder in the respective organization and attach the policy to a web service, binding, or binding operation.