Simple Object Access Protocol (SOAP) Overview:
Simple Object Access Protocol (SOAP) is a Connection or an interface between the web services or a client and web service. SOAP is operated with application layer protocols like HTTP, SMTP or even TCP for message transmission.
Figure 1 SOAP Operation
It is developed in XML language, which uses Web Service Description Language (WSDL) to generate the interface between the web services. If an independent client application or a consumer wants to connect with the web services, it needs Service Endpoint Interface (SEI) which is generated by the application. These interfaces WSDL and SEI are generated using automated tools or by manually, and they are platform independent. Universal Description, Discovery and Integration (UDDI) is a directory where web services can publish about their services and consumer can submit theirs query.
A simple SOAP message contains:
- Envelope: Identifies the XML documents, has a name space and encoding details.
- Header: Has header information like content type and character set etc.
- Body: Contains the request and response information.
- Fault: Errors and status information.
Figure 2 Example of SOAP Request and Response
The figure.2 shows the SOAP request and response, where web service is requesting for the name of the user and replying back with a message. SOAP is protocol, a set of standards defined to perform some operations, so it only transmits the data for the requests, whatever the request may be if it is validated in its mechanisms it will have reply.
Common SOAP Vulnerabilities:
1) SQL Injection:
SOAP requests are vulnerable to SQL injections, submitting a parameter as a morphed sql query can authenticate or reveal sensitive information
Before attack Functionality:
Before Performing the attack one must know the functionalities of the web service in fig.3 one can see that username parameter taking string as a input,
Figure 3 Request Functionality analysis
A random username is entered to check its operation, so it response back with the message that username does not exit, this may help to perform the attack with the possibilities.
Figure 4 Response Functionality analysis
After attack:
The request shown below is an attacker trying to access the user details by passing a sql query in the place of parameter, error message of the database will help to guess the query,
Figure 5 Database Error Message
Figure 6 SQL Injection request
If the passed query is successful in breaking the database then it will response back with the information of the users.
Figure 7 SQL Injection Response
Payloads:
Payloads for SQL injections typically involve simple morphed queries designed to make the database fetch unintended details. For instance, in the example provided using MySQL (refer to Figure 5), the database may contain multiple tables. While retrieving information from all tables may be challenging, accessing specific fields is feasible.
In Figure 3, the SOAP message requests details for an admin account by combining the username with the condition 1=1 using the OR statement and marking everything else as a comment (–). This technique forces the database to reveal all usernames and signatures. SQL injection attacks can employ various methods, including the use of characters such as ,, “”, –, OR, AND, INSERT, or other query combinations that fulfill the condition.
Patch:
To mitigate SQL injection attacks, patches can be implemented in the following ways:
- Whitelisting: This method involves allowing only specific characters through the application. By adding only permissible characters to the whitelist, such as admin, the application restricts input to these characters only.
- Sanitization: This approach entails sanitizing user input by removing unwanted characters. For example, input like admin’ OR ‘1=1’ — would be sanitized so that only admin is processed.
2) Command Injection:
Command injection is an attack that is usually performed by passing a command with the data to get different information like directory structures, sitemaps, or even sensible information related to the web application.
Figure 8 Command Injection Request (1)
In the above lookupDNS web service, a request is made with an IP address and command ls, which lists the directory structure of the application as shown below:
Figure 9 Command Injection Response (1)
In other requests, a ping command is passed with an IP address to ping the host, which is shown below:
Figure 10 Command Injection Request (2)
Figure 11 Command Injection Response (2)
Payloads:
For this type of attack, payloads are commands combined with the user input, but some commands are commonly used and some are operating system specific. Knowing the type of operating system is a simple task; one can see it from HTTP. Commands like ls, adduser, install, kill, or join, etc., can be used to perform the operation.
Patch:
For patching the command injection attack, a strict validation mechanism must be built and its functionalities implemented. The user input data is validated with the database containing the attack patterns such as 192.168.66.2; ls; and 192.168.66.2 && ping c1 localhost, ensuring it only allows alphanumeric characters. In the above command injection attack, special characters such as & or ; separate the commands and data while executing at the service end, so one must develop functionalities concerning these facts.
3) XML Injection:
In XML Injection type of attack, a morphed request of SOAP message can make changes in the database and cause serious damage to the database.
Normal Functionalities:
The createUser Functionality creates the new user in the application, which takes several parameters as input and can be seen in Fig. 12.
Figure 12 XML Request
The response will have a return statement with a message inserting the account username as seen in Fig. 13.
Figure 13 XML Response
Attack:
IIn actual XML injection, a part of the code is morphed and sent with the request so that the code will be executed on the other side. In fig. 14, create user functionality is added with additional code to exploit the service.
Figure 14 Morphed XML Request
From fig. 15, it can be seen that the web service is executing the code with a message that inserted the account username. The functionality executes the parameters inserted by the attacker rather than the actual request.
Figure 15 Response for morphed request
Payloads:
Payloads for this type of attack are actually the parameters submitted at the other end. In this case, the createUser XML tag is morphed or modified to include the details of account Alice and attached to the request so that it will execute.
Patch:
The patch for this type of attack involves making strict limits on tag strings like createUser. The length of the string must be defined, and the number of occasions or occurrences for the createUser functionality in WSDL should be specified. Based on the data and parser, a sanitization mechanism for user input should be developed. Additionally, using Document Type Definition (DTD) for validating attempted injections is considered best practice.
4) SOAP Action Spoofing:
Each HTTP request contains a field called SOAP Action, which is used to perform an operation defined in its content. It may be possible to change the content by an attacker who is operating in between the client and server, a sort of bypassing or Man in the Middle operations.
The request message shown below contains a functionality called ‘create user,’ which can be seen in both the SOAP Action field and the SOAP body.
Figure 16 SOAP Request with SOAP Action Field
Simply morphing the fields (may not be one) can change its functionalities as shown in figure.17.
Figure 17 SOAP Request with SOAP Action morphed
After changing the request and passing it to the server, the request will have a response as it seems legitimate and perform its action to delete account, can be seen in fig.18
Figure 18 SOAP Response executing morphed request
Payloads:
For this type of attack, there are no specific payloads. The SOAP Action field is considered the target. A thorough analysis of functionalities can provide clues for performing the attack. Changing only the SOAP field may not be sufficient; it might also be necessary to modify the request message according to the action performed.
Patch:
To prevent this type of attack, you must disable specific SOAP Action fields such as createUser or deleteUser in the HTTP request, or use SOAP Action terminologies that are not easily guessed. In some cases, it might be necessary to make the Action field compulsory. For such scenarios, developers should consider options like SOAPAction: “” (which means the intention of the SOAP message is given by the URI of the request) or SOAPAction: (an empty field indicating that the intention of the message is not to specify any value or URI).
5) SOAP Parameter DOS Attack:
Every SOAP request contains a parameter which is passed to fetch some data, there are some requests where an attacker can exploit the parameters to perform a denial of service attack. If the application fails to perform input validation or no boundaries for the parameter, can cause a buffer overflow and this will make the service unavailability. The figure shown below contains a parameter username without any boundary limits, so any one can pass the string of desire length to the application.
Figure 19 SOAP request without condition
If the username has limits then it will have some exception to pass the correct string this will make the application secure.
Payloads:
For this type of attack, the payloads involve understanding the data types passed in the request. Attackers exploit this by submitting maximum or excessively large values based on the data type.
Patch:
To mitigate this attack, define parameters with specific minimum and maximum length constraints or boundaries. For example, set the username parameter with a minimum length of 5 and a maximum length of 35 characters. This ensures proper validation during processing.
Figure 20 SOAP request with condition
6) WSDL Disclosure:
WSDL disclosure cannot be considered an attack itself but rather a step towards an attack. WSDL contains information about web services, and some web services, such as payment gateways or those collecting sensitive information, need to be hidden from attackers. An attacker can find a web service by simply typing ‘inurl:?wsdl’ into a search engine.
Figure 21 Web-Service Searching
Figure 22 Web service WSDL
Patch:
Web applications designed for secure data transmission should not rely solely on their inherent security. Ensure that the URL of the web service (as shown in Figure 22) is concealed from search engines and public disclosure. Additionally, maintain strict adherence to features such as Confidentiality, Integrity, and Authenticity.