Difference between revisions of "SOAPAction Spoofing"

From WS-Attacks
Jump to: navigation, search
m (1 revision imported: Import from WS-Attacks)
 
m (1 revision imported: Import from WS-Attacks)
 
(No difference)

Latest revision as of 12:26, 31 October 2015

Attack description

Each web service request contains some sort of operation that is later executed by the application logic. This operation can be found in the first child element of the SOAP Body. However, if HTTP is used to transport the SOAP message the SOAP standard allows the use of an additional HTTP header element called SOAPAction[1]. This header element contains the name of the executed operation. It is supposed to inform the receiving web service of what operation is contained in the SOAP Body, without having to do any XML parsing.

This "optimisation" can be used by an attacker to mount an attack, since certain web service frameworks determine the operation to be executed solely on the information contained in the SOAPAction attribut.


Attack subtypes

Two attack subtypes are defined:

  • SOAPAction Spoofing - MITM Attack
    We assume that an attacker is able to modify a SOAP message in transit send between web service client and web service receiver. If the receiving web service is vulnerable to the SOAPAction Spoofing attack, the attacker can insert a operation in the SOAPAction attribut that gets executed by the web service receiver. As a result, a operation that was not intended by the sender got executed in his name.

  • SOAPAction Spoofing - Bypass Attack
    Certain web services are protected by separate gateways that check only the operation of the SOAP body against a white list.
    Lets assume that an attacker sends a SOAP message with a white listed operation within the SOAP Body and a black listed operation in the SOAPAction header. The SOAP message passes the gateway without any problems since the operation in the SOAP Body is allowed. Behind the gateway the web service server chooses the black listed attack; resulting in a successful attack.
    A very good real life example of this attack can be found in [2].


Prerequisites for attack

In order for this attack to work the attacker has to have knowledge about the following thinks:

  1. Attacker knows endpoint of web service. otherwise he is not able to reach the web service.
  2. Attacker has access to WSDL file.
  3. Attacker can reach endpoint from its location. Access to the attacked web service server is possible for the attacker. This prerequisite is important if the web service is only available to users within a certain network.


Graphic representation of attack

The attack aims at executing a prohibited operation.

AttackedComponent Application.png

  • Red = attacked web service component
  • Black = location of attacker
  • Blue = web service component not directly involved in attack.


Attack example

We assume that we have a web service vulnerable to SOAPAction Spoofing with the two operations "createUser" and "deleteAllUsers". Furthermore the web service is protected by a gateway, stopping all "deleteAllUsers" calls. The "createUser" operation can be executed by anyone. The "deleteAllUsers" can only executed by authorised users who are directly connected to the web service without the gateway in between.

The attacker is located in front of the gateway. He therefore should not be able to execute the "deleteAllUsers" method.

Lisitng 1 shows a regular SOAP message calling for the creation of a new user. 

POST /service HTTP/1.1
Host: myHost
SOAPAction: "createUser"

<Envelope>
  <Header />
  <Body>
    <createUser>
      <login>johndoe</login>
      <pwd>secret</pwd>
    </createUser>
  </Body>
</Envelope>

Listing 1: Unmodified HTTP-request


In Listing 2 shows the same message modified by the attacker. The SOAP message passes the gateway since it only checks for the operations within the SOAP Body. The web service itself then executes the "deleteAllUsers" operation since he bases his decision solely on the operation given in the SOAPAction header. 

POST /service HTTP/1.1
Host: myHost
SOAPAction: "deleteAllUsers"

<Envelope>
  <Header />
  <Body>
    <createUser>
      <login>johndoe</login>
      <pwd>secret</pwd>
    </createUser>
  </Body>
</Envelope>

Listing 2: Modified HTTP-request


Attack mitigation / countermeasures

If not required, the SOAPAction attribut should be disabled. If needed, the operation within the SOAPAction and the SOAP body should always be compared before executing any operation. Any mismatch should be regarded as an attack.


Attack categorisation

Categorisation by violated security objective

The attack aims at exhausting the system resources, therefore it violates the security objective Availability.


Categorisation by number of involved parties

The "SOAPAction Spoofing - MITM Attack " is categorized as follows:

The "SOAPAction Spoofing - Bypass Attack" is categorized as follows:


Categorisation by attacked component in web service architecture


Categorisation by attack spreading


References

  1. N/A. Hacking d-link routers with hnap. http://www.sourcesec.com/Lab/dlink_hnap_captcha.pdf, 2009. Accessed 01 July 2010
  2. Leroy Metin Yaylacioglu. Business value einer web service firewall. Master’s thesis, Hochschule f ̈r Angewandte Wissenschaften Hamburg, 2008.
  3. Meiko Jensen, Nils Gruschka, and Ralph Herkenh ̈ner. A survey of attacks on web services. Springer-Verlag, 2009.
Retrieved from "http://ws-attacks.org/index.php?title=SOAPAction_Spoofing&oldid=35"