Describes how to test and exploit a series of security vulnerabilities under the SOAP protocol (1)

In the first part of the article, we discussed how to generate a SOAP request in a wsdl file by disabling the operation list, and how to automate this process through Ruby and Burp suites. In addition, we also introduce the parsing method of the content of the WSDL file. In this article, we will test and exploit a series of security vulnerabilities in the SOAP service. Not all attack behaviors are targeted at SOAP. We must have a clear understanding of this situation.

New users in this line often have the idea of preemptible, believing that all kinds of attacks that threaten the security of web services are always mysterious and difficult to prevent. However, many attacks to Web services come from the same vulnerability similar to browser application security defects.

For example, you will find that all kinds of certification standard damages and session management defects are included in our vulnerability list below. Looks familiar, right? Familiar with this, because this is the top ten OWASP vulnerability rankings we have previously introduced to you. In fact, these problems pose the same threat to web applications and Web services.

The following types of vulnerabilities are described and used in this article:

1. SOAP Injection

2. SQL Injection

3. Default content

4. Damaged authentication and session management

SOAP Injection

Although many security defects in Web services are similar or almost familiar to the public, these vulnerabilities are not only compiled for reference, you don't even need any superb technology to make full use of it. However, SOAP injection is different. The vulnerabilities it points to are not only difficult to defend against, but also have considerable requirements on the level of attackers.

So how exactly is this attack? The XML parsing engine on the server receives input information from the client. The client can be a browser, data from a web application, a mobile device, or another type of source. If the entered information is not correctly verified, the received result may be incorrect, which facilitates the attack.

Based on the above situation, we start from the attacker's standpoint, without advanced technology or in-depth understanding of the Processing Methods of the SOAP request server, it is closer to the real process of SOAP injection attacks step by step. This requires us to first prepare some extremely lengthy error messages, which may sound a bit like a security configuration error ).

Follow the following requirements:

The request is displayed normally. We will issue our own name and password here. If the request is still sent normally, the resolution will also proceed smoothly. Whether or not the access permission can be granted depends on the content of the initial request.

Now let's generate the same request, but this time we omit it

<Lname> </lname>

Label.

According to the server response results, we can see that we have made some breakthroughs:

This error warning actually indirectly tells us the code! The actual definition of this fault prompt is that if the lname variable is missing, the Code should use the logon ID parameter as an alternative. The current situation is very interesting. In this case, we need to deliberately omit the lname tag to trigger the fault prompt "II"), and then extract the logon ID tag.

Here is the new request we created:

Now, the following message is displayed:

This means that we need to use the collected authorization certificate or information to start the operation.

(Submit

<Loginid> 1 </loginid>

Label ).

This type of attack is relatively simple. It uses a simple parsing engine written in the background that contains error information. In this way, the requests we submit will be received as operations from the Administrator-level account.