Difference between revisions of "XML Signature Exclusion"
(→Attack mitigation / countermeasures)
|Line 1:||Line 1:|
, not XML Signature in on .
SOAP message of certificate . , the message is .
. SOAP the SOAP interfacethe the , the attacker .
Revision as of 11:52, 23 December 2015
- 1 Attack description
- 2 Attack subtypes
- 3 Prerequisites for attack
- 4 Graphical representation of attack
- 5 Attack example
- 6 Attack mitigation / countermeasures
- 7 Attack categorisation
- 8 References
Sometimes, it is not necessary to execute complicated XML Signature Wrapping attacks in order to execute an arbitrary functionality on a Web Service.
SOAP message validation flow consists of several independent steps: signature verification, certificate validation, business logic invocation. There exists a possibility that one of these steps is omitted, and the message is still considered to be valid.
XML Signature Exclusion attack relies on these assumptions. The attacker excludes the XML Signature from the SOAP message and sends it to the SOAP interface. If the application accepts the message, the attacker can execute arbitrary functions on the interface.
There are no attack subtypes for this attack.
Prerequisites for attack
In order to execute the attack, there are the following prerequisites:
- Attacker knows endpoint of web service. otherwise he is not able to reach the web service.
- Attacker can reach endpoint from its location.
- Attacker is in possession of a validly signed XML message or he is in possession of a valid public certificate and can construct a valid message with a missing XML Signature.
Graphical representation of attack
- Red = attacked web service component
- Black = location of attacker
- Blue = web service component not directly involved in attack.
Practical attacks were shown by Somorovsky et al., who analyzed Amazon and Eucalyptus cloud providers. The attacks allowed them to execute arbitrary methods on cloud interfaces of these two cloud providers.
It was furthermore shown that these attacks can be applied to various SAML interfaces ,. Thereby, the attacker could authenticate as an arbitrary user. It was for example possible to apply this attack on these frameworks and systems: Apache Axis2, JOSSO, Open Athens, Clarizen.
Attack mitigation / countermeasures
If authenticity and integrity should be protected, the signature has to be validated. Always.
Categorisation by violated security objective
Categorisation by number of involved parties
Categorisation by attacked component in web service architecture
Categorisation by attack spreading
- Juraj Somorovsky, Mario Heiderich, Meiko Jensen, Jörg Schwenk, Nils Gruschka, Luigi Lo Iacono. All Your Clouds are Belong to us – Security Analysis of Cloud Management Interfaces. In Proceedings of the ACM Cloud Computing Security Workshop (CCSW), 2011. https://www.nds.rub.de/research/publications/amazon-hacking/
- Juraj Somorovsky, Andreas Mayer, Jörg Schwenk, Marco Kampmann, Meiko Jensen. On Breaking SAML: Be Whoever You Want to Be. In Proceedings of the 21st USENIX Security Symposium, 2012
- Christian Mainka, Vladislav Mladenov, Florian Feldmann, Julian Krautwald, Jörg Schwenk. Your Software at my Service -- Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In Proceedings of the ACM Cloud Computing Security Workshop (CCSW), 2014. https://www.nds.rub.de/research/publications/saml-saas/
- Juraj Somorovsky. On the Insecurity of XML Security. PhD thesis supervised by Jörg Schwenk and Kenny Paterson, Ruhr University Bochum. https://www.nds.rub.de/research/publications/xmlinsecurity/