Supported Versions: 10.0 & above
Purpose
This tutorial explain how to configure XML threat protection rule in API Gateway
Malicious attacks on XML applications typically involve large, recursive payloads, XPath/XSLT or SQL injections, and CData to overwhelm the parser and eventually crash the service.
Applying XML threat protection in the API Gateway helps minimize the risk from such attacks by defining some limits on the structure.
Go to Policies tab/ Threat Protection / Rules. Add rule.
Note: If the value is not specified, system will take the default value of -1 (which means unlimited)
|
Property |
Description |
|
Namespace prefix length |
Maximum number of characters allowed in a Namespace Prefix within an element in the XML file. |
|
Namespace URI length |
Maximum number of characters allowed in a namespace URI within an element in the XML file. |
|
Namespace count per element |
Maximum number of characters allowed in a namespace within an element in the XML. |
|
Child count |
Maximum number of child elements allowed per element in the XML document. |
|
Attribute name length |
Maximum number of characters allowed in an attribute name in the XML file. |
|
Attribute value length |
Character limit for attribute values present in the XML document. |
|
Attribute count per element |
Maximum number of attributes allowed within an element in the XML. |
|
Element name length |
Maximum number of characters allowed in an element name in the XML file. |
|
Text length |
Character limit for text nodes present in the XML document. |
|
Comment length |
Character limit for comments present in the XML document. |
|
Processing instruction target length |
Maximum number of characters for the target of any processing instruction text present in the XML file. |
|
Processing instruction data length |
Maximum number of characters for the Processing Instruction Text present in the XML file. Example: type=”text/xsl “, href=”/style.xsl“. Here, length of type and href are checked. |
|
Node depth |
Maximum number of nodes allowed in the XML. |
|
Applicable content types |
Content types you want to enforce this policy |
For you to explain I will take a very simple use case. Say we want to limit the number of elements in the XML. Below is my configuration, which should restrict the requests with element count > 4.
Once we define the required values and enable the filter. This gets part of the threat-protection rules.
These threat protection rules gets executed only when the request comes from an external port. So define an external port in the apigateway and enable it.
To show the scenario, I have a native service which just returns the result as success.
Below is the positive case, where the element count is only 4
Now if we increase the element count by 1, the request should fail as it exceeds our configuration
We return a forbidden(403) status and the error message we configured for the rule.
Note: One more interesting feature is the applicable content types. You can have multiple such filters with different content types and different values.
Say for example, you want to allow larger size data for a particular content type. you can do that by creating a different filter with higher values, this way we can selectively allow/restrict payload sizes for different content types.