Threat Protection Assertions

The Threat Protection assertions help protect against common web service and XML threats.
This category may also include custom-created encapsulated assertions. For more information, see Encapsulated Assertions.
Automatic Threat Protection
In addition to using the Threat Protection assertions, the 
API Gateway
comes with a variety of built-in threat protection, including those for:
TCP/IP-based attacks
Coercive parsing and XML bomb attacks
External entity attacks
Schema poisoning
WSDL scanning
XML routing detours
To ensure that the built-in protections are applied to the request, the service policy must include at least one assertion that accesses the request body—the Protect Against Document Structure Threats Assertion is most commonly used. (It is not necessary to use a Threat Protection-related assertion: any assertion that accesses the request body suffices.)
TCP/IP-Based Attacks
API Gateway
 protects against all the common TCP/IP-based attacks, such as ICMP flood, SYN flooding, "ping of death", and various routing redirect style attacks.
Packet-level attacks are handled by the 
API Gateway
 default OS-level configuration (in particular, by the default firewall configuration). 
Packet-level attacks are not logged.
Coercive Parsing and XML Bomb
A coercive parsing attack attempts to exploit the "bolt-on" interfaces used to link legacy systems with XML components in an existing infrastructure. The attack tries to overwhelm a system's processing capabilities or install malicious mobile code.
This attack is also known as a "DTD Entity Expansion Attack". According to the SOAP specifications, a SOAP message must not contain a DTD declaration. The 
API Gateway
 can prevent messages containing DTD declarations from passing through, by terminating them before any policy processing begins. To block DTD declarations, ensure that the Protect Against XML Document Structure Threats assertion is present in the service policy or in a global policy fragment.
From a technical perspective, the XML parser will not allow DOCTYPE declarations. When the parser encounters a message containing a DOCTYPE, it terminates parsing without expanding the entity or entities. The 
API Gateway
 then logs and audits a warning that a message was badly formed. This allows administrators to monitor potential intrusion attempts, while keeping the protected services safe.
External Entity Attack
XML can be used to build documents dynamically by pointing to a URI where the actual data exists. These external entities may not be trustworthy, as an attacker could replace the data being retrieved with malicious code.
By default, the 
API Gateway
 does not resolve external entities and the 
API Gateway
 can be configured using the Evaluate Request XPath and Evaluate Response XPath assertions to block all messages containing references to external entities.
Schema Poisoning
A schema describes the constraints and structure of a message, as well as optional processing instructions. Parsers use schemas to interpret web service messages. Since schemas describe the necessary preprocessing instructions, they are vulnerable to tampering if not stored securely.  
Schema poisoning involves an attacker attempting to compromise a system by replacing or tampering with the schema. To protect against this, the 
API Gateway
 does not load schemas from unauthorized locations. All schemas must be loaded by the administrator; dynamic loading is not permitted.
WSDL Scanning
A WSDL document describes a web service, including what operations are supported. In addition to this information, a WSDL may expose details about the implementation that could be used by an attacker. An attacker might cycle through the various command and string combinations to discover unintentionally related or unpublished application program interfaces.
API Gateway
 selectively proxies all internal WSLDs, shielding access to the original WSDLs on the application servers. The 
API Gateway
 will deny direct access to all WSDLs even when an attacker guesses a related unpublished WSDL. By preventing unauthorized access to a web service (and its WSDL), this type of information scanning is blocked.
XML Routing Detours
XML routing detours can occur if an attacker sends a message to a Web service containing bogus routing information to override the normal routing. The detoured message can then pass through unknown or untrusted hosts, making it possible for the attacker to view or modify the contents of the message. This rerouting is prevented when any of the Policy Manager routing assertions are used. These assertions explicitly define the route of the message and overriding the route is not possible. For more information, see Message Routing Assertions.
XML routing may also occur if WS-Routing (Web Services Routing) is used by the sender/receiver of the message, because this specification permits the source to define the route of a message.
Although the 
API Gateway
 enforces strict, explicit routing of messages, intermediates can also be prevented from viewing and or changing sensitive content by using the extensive encryption and signature facilities within the 
API Gateway