Web app security is very popular among security testers. Web applications are viewed as a primary attack vector by developers, organizations, and security testers. Web services are a secondary attack vector because they are so new compared to web apps. It is often found that web services have fewer security features than web applications. This is due to a lack of knowledge or concern. This makes web services a popular attack vector that is easy to penetrate according to the attacker’s perspective.
Learn more about the OWASP Top Ten
Learn how to identify and mitigate the most common security threats in web applications, such as injections attacks, cross site scripting, broken authentication, and other. GET STARTED
This article was also written because web services have increased dramatically in the last few years and the sensitive data that flows through web services is another reason. Web services are a powerful attack vector.
Mobile applications have caused a rapid rise in web service usage. Mobile applications have seen rapid growth in usage. Most mobile apps use some type of web service. This has resulted in a significant increase in web services. Enterprise software, which contains a lot sensitive data, is a major user of web services. Web services are a potential attack vector due to their inability to implement security measures and the limited resources.
This article will discuss details about web services, their testing methods, and tools that are used to test them.
SOA:
It is important to understand the basics of a web service before we can begin to use it. A web service is the implementation and management of SOA. Let’s begin with SOA.
SOA stands to Service riented Architecture. Wikipedia states that Service-oriented Architecture ( SOA ) is a type of software design and architecture design pattern that uses discrete pieces to provide service functionality. This is known as Service-orientation. A service is an independent logical representation of a repeatable activity or function. Other software applications can combine services to provide all the functionality of large software applications.
It is very similar to client-server architecture, except that a client is a consumer of services and the server is a provider. A service is an activity that is clearly defined and does not depend on other services. The service consumer requests the particular service in the format provided by the service provider. In return, the service provider provides a service response in the form shown in Fig 1.
Fig 1. Service Oriented Architecture (SOA).
What is web service?
Web services are a standard way to establish communication between Web-based applications using open standards over the internet protocol backbone. Web applications generally work with HTML and HTTP, while web services use XML and HTTP. This has some advantages over web apps. Web services can be used in heterogeneous environments because HTTP is transfer-independent and XML is data-independent.
Why should you use web services?
Web services offer some advantages over web apps. These are just a few:
- Language interoperability (Programming language independence)
- Platform Independent (Hardware/OS independent)
- Function reuse
- Firewall friendly
- Standardized Protocols
- Stateless Communication
- Economic
Web application and web service differences:
A web application is an application accessible through a web browser on a client’s computer. A web service, however, is software that allows different computers to communicate with one another over a network. Web services don’t usually have a user interface because they are used in applications as components. A web application has a GUI and is a complete application. Web services can take a web app to the next level. They allow it to communicate with other web applications on different platforms and transfer data, allowing it support heterogeneous environments.
Web Services Components:
- 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: applications can be written in any programming languages. These components are already described in SOA division.
Extensible markup Language (XML), : can be used to encode data or form the SOAP message.
Simple Object Access Protocol, (SOAP),: allows applications to exchange information via HTTP. It is XML-based. To send XML requests, web services use a SOAP format. SOAP clients send a SOAP message back to the server. The server replies with a SOAP message and the requested service. As shown in Figure 2, the entire SOAP message is enclosed in a SOAP envelope.
Fig 2: SOAP Message Structure
The body block contains the actual data, while the metadata is typically carried by the header.
Fig 3 is a typical SOAP request.
Fig 3: SOAP Request
The service provider will respond to the SOAP request if the consumer has sent it properly. Fig 4 shows a typical SOAP response.
Fig 4: SOAP Response
Web Services Description Language: is an XML-formatted language that UDDI uses. It describes the capabilities and features of the web service. In simple terms, “Web Services Description Language” is an XML-based language that describes Web services and how they can be accessed.
Security testing web services can be complicated. Understanding WSDL files is a great help in manual security testing. We can break down the WSDL file structure into two parts based on our definition. The 1 st section describes the web service, while the 2 and 3 sections tell you how to access it. Let’s begin with the basic WSDL structure, as illustrated in Fig 5.
Fig 5. Basic WSDL File Structure
The Fig 5 image focuses only on the most important elements in the WSDL file. Table 1 explains exactly what each element contains.
| Elements | What is it made of |
| Definitions | All XML elements are stored under the definition element. This element is also known as the root or parent element in the WSDL file. |
| Types | These are all the data types and schema types that have been defined. |
| Message | This is a dependent element. The data types element defines the message. Later, it is used in the operation element. |
| port Type | Element gathers all operations in a web service. |
| Operation | Collect of input, output and fault messages as described in Message element. |
| Enter message | It is nothing more than the parameters of SOAP request. |
| Output message | It is nothing more than the parameters of SOAP response. |
| Binding | This element links part 2 to WSDL file and part 1 to the element. It allows you to specify the protocol that you want to use. |
| soap: binding | It runs the SOAP message. |
| Service | This contains the name of the service provider. |
| port | It gives the physical location or path of the web server, so that service consumers can connect to service provider. |
Table 1: Definition of Different Elements in WSDL File
Fig 6: A WSDL file
Universal description, Discovery and Integration (UDDI: is an online distributive directory that allows service providers to register.
web services via its WSDL. UDDI will present a list of service providers that offer the service. The service consumer will search for suitable web services. The service consumer selects one provider and receives the WSDL.
Fig 7 shows a typical UDDI connection.
Fig 7: UDDI Link
What are web services?
Let’s take all that we have discussed above and redefine web services. Web services allow two Web-based applications to communicate by standardizing their communication using XML and SOAP. XML is used for data encryption in the form a SOAP-based message. SOAP is used for information exchange over HTTP, WSDL, and to describe web services capabilities. UDDI is used by the service provider list as shown in Fig 8. “
Fig 8: Web Service Description
If a service customer wants to use a web service in real-time, it will need to know the provider. Once a service provider has validated a consumer, it will send the WSDL file directly to the consumer. The service consumer then creates an XML message to request the required service.
If a service customer is unaware of the service provider, they will go to UDDI to search for the desired service. UDDI will return a list of service providers that offer this particular service. Next, the service consumer selects one provider to generate an XML message. This request is in the form a SOAP message. The service provider will then return a response. Generally, web service testing assumes that the service consumer is familiar with the service provider. To begin testing a webservice we need to request the WSDL file.
How do you test web services?
Web services use a similar testing approach to web applications. There are some differences between web services and web applications, but those will be discussed later. There are three types of web services testing:
- Black Box Testing
- Grey Box Testing
- White Box Testing
Black box testing requires that the tester concentrate more on authentication as he/she is only given a WSDL file. Grey box is my favorite because you can see the responses and requests from other users to better understand them. This will allow you to better understand user roles, data validations, and authentication mechanisms.
Our testing approach will vary depending on the scenario and scope. All of these approaches will be covered, but for now, we will stick to black box testing.
How do I start?
Let’s say that you want to test for web services associated with a web application http://www.example.com, it’s a black box testing and you have no details of the web service associated. (Normally, if a client wishes to test their web service they will give you the WSDL files but for the moment we assume that we do not have the WSDL.
Next, you can begin web services fingerprinting. We have already mentioned that all web service descriptions can be found in WSDL. You can then use google to fingerprint that particular WSDL file using special notations like filetype (Fig 9).
Fig 9: Google Dork is used to find WSDL
Fig: 10 (Search Result)
As shown in Fig 10, Google will give you the link to the WSDL file for that web application. You can either use your own dorks, or search the internet for dorks that can help you find other web services that you may be able to apply.
You have now created the WSDL file. What next? We need tools for penetration testing. Here we will also use tools to test web services. In this article, I will discuss tools for web services testing.
Conclusion
Web services are becoming more popular and an attack vector. It is also more vulnerable due to the low importance they receive. Web services should be given the same importance by developers, testers, and organizations as web applications.