Web Services Penetration Testing Part 1

Introduction:

Web application security is quite popular among pen testers, so organizations, developers and pen testers treat web application as primary attack vector. And, as web services are relatively new as compared to web applications, it is considered a secondary attack vector. Due to a lack of concern or knowledge, it is generally found that the security measures implemented in a web service are worse than those that are implemented in web applications, which makes the web services a favorite attack vector and easy to penetrate from the attacker's point of view.

Another reason for this article is that the use of web services has increased in the last couple of years in a major ratio and also the data which flows in web services are very sensitive. This makes web services again an important attack vector.

The use of web services increased suddenly because of mobile applications. As we all know, the growth in the use of mobile applications has increased very rapidly, and most mobile applications use some sort of web services, thus greatly increasing the use of web services. Web services are also mostly used by enterprise-level software that carries lots of sensitive data. Due to the lack of security implementations and few resources for web services testing, web services have become a possible attacking vector.

In this article we will focus on details of web services, its testing approach, tools used for testing, etc.

SOA

Before we try to penetrate a web service, we must know its basics. As a web service is an implementation of SOA, let's start with SOA.

SOA stands for service oriented architecture. According to Wikipedia, "Service-oriented architecture (SOA) is a software design and software architecture design pattern based on discrete pieces of software that provide application functionality as services, known as service-orientation. A service is a self-contained logical representation of a repeatable function or activity. Services can be combined by other software applications that together, provide the complete functionality of a large software application."

In simple words it is quite similar to client server architecture, but here the client is a service consumer and the server is a service provider. Service is a well-defined activity that does not depend on the state of other services. Service consumer requests a particular service in the format used by service provider and service provider returns with a service response, as shown in Fig 1.

Fig 1: Service Oriented Architecture (SOA)

What Is Web Service?

Web service is a standardized way of establishing communication between two web-based applications by using open standards over an Internet protocol backbone. Generally web applications work using HTTP and HTML, but web services work using HTTP and XML. Due to this, it has some advantages over web applications. HTTP is transfer-independent and XML is data-independent and the combination of both makes web services support a heterogeneous environment.

Why Use Web Service?

Web services have some added advantages over web applications. Some are listed below:

1. Language interoperability (programming language independent)
   
2. Platform independent (Hardware and OS independent)
   
3. Function reusability
   
4. Firewall friendly
   
5. Use of standardized protocols
   
6. Stateless communication
   
7. Economic
   

Difference between Web Application and Web Services

A web application is an application that is accessed through a web browser running on a client's machine whereas a web service is a system of software that allows different machines to interact with each other through a network. Most of the times, web services do not necessarily have a user interface since they are used as a component in an application, while a web application is a complete application with a GUI. Furthermore, web services take web application to the next level because they is used to communicate or transfer data between web applications running on different platforms, allowing it to support heterogeneous environment.

Components of Web Services

1. Service consumer
   
2. Service provider
   
3. XML (extensible markup language)
   
4. SOAP (simple object access protocol)
   
5. WSDL (web services description language)
   
6. UDDI (universal description, discovery, and integration)
   

Service Consumer and Service Provider

Service consumer and service provider are generally applications can be written in any programming language. The work of both this components is already mentioned in SOA division.

Extensible Markup Language (XML)

XML is used to encode data and form the SOAP message.

Simple Object Access Protocol (SOAP)

SOAP is an XML-based protocol to let applications exchange information over HTTP. Web services use the SOAP format to send XML request. The SOAP client sends a SOAP message to the server for services and the server responds with another SOAP message along with the requested service. The entire SOAP message is packed in a SOAP envelope, as shown in Fig 2.

Fig 2: SOAP Message Structure

The actual data flows in the body block and the metadata usually carried by the header block.

A typical SOAP request looks like Fig 3.

[html]

POST /ws/ws.asmx HTTP/1.1

Host: www.example.com

Content-Type: text/xml; charset=utf-8

Content-Length: length

SOAPAction: "http://www.example.com/ws/IsValidUser"

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns_xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns_xsd="http://www.w3.org/2001/XMLSchema" xmlns_soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<IsValidUser xmlns="http://www.example.com/ws/">

<UserId>string</UserId>

</IsValidUser>

</soap:Body>

</soap:Envelope>

[/html]

Fig 3: SOAP Request

If the service consumer sends a proper SOAP request, then the service provider will send an appropriate SOAP response. A typical SOAP response looks like Fig 4.

[html]

HTTP/1.1 200 OK

Content-Type: text/xml; charset=utf-8

Content-Length: length

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns_xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns_xsd="http://www.w3.org/2001/XMLSchema" xmlns_soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<IsValidUserResponse xmlns="http://www.example.com/ws/">

<IsValidUserResult>boolean</IsValidUserResult>

</IsValidUserResponse>

</soap:Body>

</soap:Envelope>

[/html]

Fig 4: SOAP Response

Web Services Description Language (WSDL)

This is an XML formatted language used by UDDI. It describes the capabilities of web services as a collection of communication end points with the ability of exchanging messages. Or in simple words, "Web services description language is an XML-based language for describing web services and how to access them."

As per pen testing web services concerns, understanding a WSDL file helps a lot in manual pen testing. We can divide WSDL file structure into two parts according to our definition. 1^st part tells what the web service does (describing web service) and the 2^nd parts tells how it does (how to access them). Let's start with basic WSDL structure as shown in Fig 5.

Fig 5: Basic WSDL File Structure

The Fig 5 image only focuses on some of the important elements of the WSDL file. What the element exactly contains is defined in Table 1.

Table 1: Defining Different Elements of WSDL File

Fig 6: A WSDL file

Universal Description, Discovery and Integration (UDDI)

This is a distributive directory on the web where every service provider who needs to issue web services registers itself using its WSDL. A service consumer will search for appropriate web services and UDDI will provide the list of service providers offering that particular service. The service consumer chooses one service provider and gets the WSDL.

A typical UDDI link looks like Fig 7.

Fig 7: UDDI Link

What Are Web Services?

Let's redefine web services from all the things what we covered above. "Web services are a standardized way of establishing communication between two web-based applications by using XML, SOAP, WSDL, UDDI, and open standards over an Internet protocol backbone. Where XML is used to encode the data in the form of soap message, SOAP is used to exchange information over HTTP, WSDL is used to describe the capabilities of web services, and UDDI is used to provide the list of service provider details as shown in Fig 8. "

Fig 8: Web Service Description

In a real-time scenario, if a service consumer wants to use some sort of web services then he/she must know the service provider. If a service provider validates a service consumer it will provide the WSDL file directly and then the service consumers create a XML message to request the required service in the form of a SOAP message and the service provider returns a service response.

On the other hand, if the service consumer is not aware of the service provider, he/she will visit UDDI and search for the required service. The UDDI returns the list of service providers offering that particular service. Then, by choosing one service provider, the service consumer again generates an XML message to request the required service in the form of a SOAP message, as specified in the WSDL file of that service provider and the service provider returns a service response. Generally, in web service testing, we assume the service consumer knows the service provider, so to start testing a web service we must ask for the WSDL file to start with.

How to Test Web Services?

The testing approach for web services is quite similar to the testing approach used in web applications. There are certain differences, but we will discuss those in a later part. Web services testing are also categorized in three types:

1. Black box Testing
   
2. Grey box Testing
   
3. White box Testing
   

In black box testing, a tester has to focus more on authentication because he/she will be provided only with WSDL file. I prefer grey box most, because it's better to have some sample request and responses to analyze the web services better. It will help to understand the user roles, authentication mechanism and data validations etc.

Depending up on the scope and scenario, our testing methodology will change. We will focus on all these testing approaches but now we will start with black box testing.

Where to Start?

Let's say that you want to test for web services associated with the web application http://www.example.com. It is a black box testing and you have no details of web service associated with it. (Generally, if a client wants to test their web services, they will provide you the WSDL file but for now we will assume that we don't have the WSDL file)

Then you can start with web services fingerprinting. As we already covered that all the web services descriptions are present in WSDL, you can use Google to fingerprint the WSDL file of that particular web application, using special notations such as filetype shown in Fig 9.

Fig 9: Use of Google Dork to Find WSDL

Fig: 10 (Search Result)

As shown in Fig 10, Google will provide you the link to the WSDL file associated with that particular web application. You can use your own dorks and there are dorks available in Internet to search for different web services and you can apply them also.

Now you have the WSDL file. What to do next? As in any kind of penetration testing, we need some tools; here also we will use some tools to test for web services. And I will cover tools used in web services testing in the next part of the article.

Conclusion:

The sudden increase in the use of web services makes it an important attack vector and the lack of importance given to it makes it more vulnerable. Organizations, developers, and testers need to give web services equivalent importance as web applications.

Reference:

http://www.w3schools.com/webservices/default.asp

http://en.wikipedia.org/wiki/Service-oriented_architecture

http://media.blackhat.com/bh-us-11/Johnson/BH_US_11_JohnsonEstonAbraham_Dont_Drop_the_SOAP_WP.pdf

http://www.differencebetween.com/difference-between-web-service-and-vs-web-application/