Introduction:
Web application security is quite popular among the pen testers. So organizations, developers and pen testers treat web applications as a primary attack vector. As web services are relatively new as compared to web applications, it’s considered as secondary attack vector. Due to lack of concern or knowledge it is generally found that security measures implemented in a web service is worse than what is implemented in web applications. Which makes the web service a favorite attack vector and easy to penetrate as per the attacker’s point of view.
Another reason to write this article is that the use of web services increased in 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 of usage for mobile applications has increased rapidly, and most mobile applications use some sort of web service. Which has relatively increased the use of web services. Web services are also mostly used by enterprise level software which carries a lot of sensitive data. Due to the lack of security implementations and resources available, web services play a vital role making it 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 starting to penetrate a web service we must know its basics. As a web service is the 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 a client is a service consumer and server is a service provider. Service is a well defined activity that does not depend on the state of other services. A service consumer requests a particular service in the format used by the service provider and the service provider returns with a service response as shown in Fig 1.
Fig 1: Service Oriented Architecture (SOA)
What is Web Service?
A 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. Which as added some advantages over web applications. HTTP is transfer independent and XML is data independent, 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:
- Language Interoperability (Programming language independent)
- Platform Independent (Hardware and OS independent)
- Function Reusability
- Firewall Friendly
- Use of Standardized Protocols
- Stateless Communication
- 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 it’s used as a component in an application, while a web application is a complete application with a GUI. Furthermore, web services will take a web application to the next level because it’s used to communicate or transfer data between web applications that run on different platforms allowing it to support a heterogeneous environment.
Components of Web Services:
- Service Consumer
- Service Provider
- XML (Extensible Markup Language)
- SOAP (Simple Object Access Protocol)
- WSDL (Web Services Description Language)
- UDDI (Universal Description, Discovery and Integration)
Service Consumer and Service Provider: are applications that can be written in any programming language. The work of both these components is already mentioned in SOA division.
Extensible Markup Language (XML): is used to encode data and form the SOAP message.
Simple Object Access Protocol (SOAP): is a XML-based protocol that lets applications exchange information over HTTP. Web services use a SOAP format to send XML requests. A SOAP client sends a SOAP message to the server. The server responds back again with a 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 is usually carried by the header block.
A typical SOAP request looks like Fig 3.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| POST /ws/ws.asmx HTTP/1.1Host: www.example.comContent-Type: text/xml; charset=utf-8Content-Length: lengthSOAPAction: "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><UserId>string</UserId></IsValidUser></soap:Body></soap:Envelope> |
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.
1
2
3
4
5
6
7
8
9
10
11
12
| HTTP/1.1 200 OKContent-Type: text/xml; charset=utf-8Content-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><IsValidUserResult>boolean</IsValidUserResult></IsValidUserResponse></soap:Body></soap:Envelope> |
Fig 4: SOAP Response
Web Services Description Language (WSDL): is really an XML formatted language used by UDDI. It describes the capabilities of the web service as, the 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 are concerned, understanding of WSDL file helps a lot in manual pen testing. We can divide WSDL file structure in to two parts according to our definition. 1st part describes what the web service and the 2ndparts tells 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.
| Elements | What it contains |
| definitions | All the XML elements are packed under definition element. It is also called as root or parent element of the WSDL file. |
| types | All the schema types or data types defined here. |
| message | This is a dependent element. Message is specified according to the data types defined in types element. And used in sideoperation element later. |
| portType | Element collects all the operations within a web service. |
| operation | Collection of input, output, fault and other message as specified in message element. |
| input message | It’s nothing but the parameters of the method used in SOAP request. |
| output message | It’s nothing but the parameters of the method used in SOAP response. |
| binding | This element connects part 2 of WSDL file with part1 associating itself to the portType element and allows to define the protocol you want to use. |
| soap:binding | It formulates the SOAP message at runtime. |
| service | Contains name of all the services provided by the service provider. |
| port | It provides the physical path or location of web server so that service consumer can connect with service provider. |
Table 1: Defining Different Elements of WSDL File
Fig 6: A WSDL file
Universal Description, Discovery and Integration (UDDI): is a distributive directory on the web, where every service provider who needs to issue registered
web services using its WSDL. The 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.
web services using its WSDL. The 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 the web services from all the things what we’ve 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 a SOAP message. SOAP is used to exchange information over HTTP, WSDL and 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 service, then it must know the service provider. If a service provider validates a service consumer it will provide the WSDL file directly and then the service consumer creates a XML message to request for a required service in the form of a SOAP message and the service provider returns a service response.
On other hand if a service consumer is not aware of the service provider, it 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 again the service consumer generates a XML message to request for a required service in the form of a SOAP message, as specified in the WSDL file of that service provider. The service provider then returns a service response. Generally in web service testing we assume the service consumer and the service provider know each other, so to start testing a web service we must ask for the WSDL file.
How to test Web Services?
The testing approach of web services is quite similar to the testing approach used in web applications. Though there are certain differences, but we will discuss those at a later time. Web services testing is categorized in 3 types:
- Black Box Testing
- Grey Box Testing
- White Box Testing
In black box testing the 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 requests and responses to analyze the web services better. It will help to understand the user roles, authentication mechanism and data validations etc.
Depending upon the scope and scenario, our testing methodology will change. We will focus on all these testing approaches but to start with now we will use black box testing.
Where to Start?
Let’s say that you want to test for web services associated with a web applicationhttp://www.example.com, it’s a black box testing and you have no details of the web service associated. (Generally if a client wants to test their web services they will provide you the WSDL file but for now we assume that we don’t have the WSDL file)
Then you can start from web services fingerprinting. As we already covered that all the web services descriptions are present in WSDL so you can use google to fingerprint the WSDL file of that particular web application using special notations such as filetype shown in Fig 9.
Depending upon the scope and scenario, our testing methodology will change. We will focus on all these testing approaches but to start with now we will use black box testing.
Where to Start?
Let’s say that you want to test for web services associated with a web applicationhttp://www.example.com, it’s a black box testing and you have no details of the web service associated. (Generally if a client wants to test their web services they will provide you the WSDL file but for now we assume that we don’t have the WSDL file)
Then you can start from web services fingerprinting. As we already covered that all the web services descriptions are present in WSDL so you can use google to fingerprint the WSDL file of that particular web application using special notations such as filetype shown in Fig 9.
1
| www.example.com filetype:WSDL |
Fig 9: Use of Google Dork to Find WSDL
Fig: 10 (Search Result)
As shown in Fig 10, Google will provide you the link of the WSDL file associated with that particular web application. You can use your own dorks or there are dorks available on internet to search for different web services which you can apply also.
Now you have the WSDL file, what is next? As in any kind of penetration testing we need some tools, here also we will use some tools to test for web services. I will cover tools used in web services testing in the installment of this article.
Conclusion:
The sudden increase in the use of web services makes it an important attack vector and the lack of importance it is given makes it more vulnerable. Organizations, developers and testers need to give web services equivalent importance as web applications.
Reference:
Fuente: http://resources.infosecinstitute.com/web-services-penetration-testing-part-1/
No hay comentarios:
Publicar un comentario