What Are the Risks of XML? – Blog Series – Part #04
As in the last article in this series, the focus here is once again on finding security vulnerabilities in the processing of XML. This time, the SOAP protocol [1]—which we have already reported on—is the focus of the investigation. SOAP is often secured using the WS-Security standard [2]. In general, WS-Security defines special SOAP headers that allow the content (body) to be signed and/or encrypted. In this article, we analyze the sample clients and servers provided by the Apache Rampart [3] project. We analyze these using the WS-Attacker tool, which was co-developed by Hackmanit.
Setting up the Test Environment
To follow the steps of the security analysis yourself, or to try out attacks yourself, you can download and start the Rampart sample web servers using the following steps; the servers can then be reached under localhost:8080. If you do not want to do this yourself, you can skip this section.
- Install and set up Docker.
- Clone the repository https://github.com/RUB-NDS/WS-Attacker or download and unpack jdk..
- In the downloaded folder, execute the following commands in the console:
docker build -t "apache" apache-ws
docker run -it --rm --network host apache service.02
This executes the server for example 02. The corresponding requests from a client can be executed with:
docker run -it --rm --network host apache client.02
If everything is set up correctly, you should end up with:
BUILD SUCCESSFUL
- Install and set up Java Development Kit 7 or 8.
- Execute the following command in the
ws-attackerfolder to start WS-Attacker:
java -jar WS-Attacker-1.9-SNAPSHOT.jar
We provide a compiled version of the WS-Attacker for this project, if you want to be up to date it may be worth compiling the tool yourself. All information can be found on the WS-Attacker project page.
Wireshark, for example, can be used to view the messages exchanged between the browser and server. Information on setting up and using Wireshark can be found here.
Automatic SOAP Security Analysis
1. Load WSDL
If WS-Attacker is started as specified above and service.02 is running correctly, the tool recognises the server and its operations when you click on ‘Load’ in the ‘WSDL Loader’ tab. The path to the WSDL should be automatically set to http://localhost:8080/axis2/services/sample02?wsdl. The Web Services Description Language (WSDL) is an XML-based language that describes the endpoints of a server and the accepted message types. It is used to describe all the details of a Web API that is based on XML. WS-Attacker loads this file and uses the stored information for possible attacks.
2. Load Example Request
In order for WS-Attacker to work, we need a valid request that the server accepts. To get this, we run the client and record the connection with Wireshark. The recorded connection should look something like Figure 1.
Wireshark recording of a SOAP/WS-Security connection. (Figure 1)
There are many ways to obtain the XML text sent in Wireshark. One is—as in Figure 1—to select the XML request, then right-click on ‘eXtensible Markup Language’ and select ‘Copy’/‘Copy Bytes as Printable Text’. If you encounter problems with this step, you will find the entire recording and the message we used in the data folder in the repository for this project.
The resulting XML request can now be entered in WS-Attacker in the ‘Test Request’ tab under ‘XML Request’ (see Figure 2). After ‘Send’ has been executed, the response from the server is displayed in ‘XML Response’.
WS-Attacker – Successful Test Request. (Figure 2)
3. Execute Attacks
The available attacks can be selected and configured in the ‘Plugin Configurator’ tab. In this example, we select the plugins shown in Figure 3 and do not make any changes to the configuration.
WS-Attacker – Selection of attacks. (Figure 3)
How certain attacks are carried out can be found in the official WS-Attacker documentation [4]. There are also further sources on existing attacks and instructions on how to set up certain plugins.
4. Evaluate Attacks
If all previous steps have been carried out correctly, the automatic evaluation can be carried out in the ‘Attack Overview’ tab. The results for example 2 can be seen in Figure 4
WS-Attacker – Results of the automatic security analysis of the WS-Attacker on example 2 of the Apache Rampart implementation. (Figure 4)
As can be seen, the WS-Attacker has successfully identified vulnerabilities for the ‘Compression Attack’ and ‘XML Element Count Attack’ attacks. The descriptions in Figures 5 and 6 explain what these attacks are.
Compression Attack – The first of the two attacks that WS-Attacker recognised as a vulnerability. (Figure 5)
XML Element Count Attack – The second of the two attacks that WS-Attacker identified as a vulnerability. (Figure 6)
What Happens Next?
Just by simply running the WS-Attacker, we were able to find two potential security issues in the reference implementation. However, this does not mean that the implementation is secure against all other attacks. Especially the attacks on the signature and the encryption could—with a deep configuration—possibly still be successful. What exactly the security gaps found mean for an implementation must be analyzed on a case-by-case basis.
This article concludes the XML blog series. We hope that we have been able to convey the topic to you well. A blog series like this can only impart knowledge and help you to secure your systems to a limited extent. If you have any questions about the topics covered here, or if you would like to implement or test specific security measures, please feel free to contact our experts in the field. Only by analyzing your systems in depth can we recommend really good security measures.
Blog Series – What Are the Risks of XML? – All parts at a glance
Part #01 – XML – An Overview
Part #02 – Where Is XML Used in Practice?
Part #03 – Finding XXE Attacks in 3 Steps
Part #04 – Discover Security Vulnerabilities in SOAP Web Services
Follow us on X (Twitter) or Linkedin and don't miss any of our future blog posts.
Sources
- http://www.w3.org/TR/SOAP/
- Web Services Security v1.1.1 on https://www.oasis-open.org/standards
- https://axis.apache.org/axis2/java/rampart/index.html
- https://master.dl.sourceforge.net/project/ws-attacker/WS-Attacker%201.3/Documentation-v1.3.pdf
Our Experts Develop the Optimal Solution for You
XML Parsing – XML Security – SOAP
Are you faced with the decision of how to securely process XML and optimally protect your customer data? Or are you already using XML and wondering if your implementation is secure?
We will be glad to advise you; contact us for a no-obligation initial consultation. We support you with the following services and solutions:
IT Security Consulting | Training | Penetration Tests
Don't hesitate and find your way to secure APIs with us. We look forward to supporting you with your projects.

Your Contact for XML Security and SOAP
Prof. Dr. Juraj Somorovsky
juraj.somorovsky@hackmanit.de

