Web Services Penetration Testing

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:

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 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:

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: 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.

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>

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.

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>

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.

A typical UDDI link looks like Fig 7.

http://anything.example.org/juddi/inquiry

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:

1. Black Box Testing
2. Grey Box Testing
3. 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.

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.

Tools

Tools play a very important role in any type of penetration test. But unfortunately, the availability of tools to test web services is limited, compared to web applications. The majority of web service testing tools are built for quality assurance and not for security testing. The approach used to conduct web service testing are mostly from developer’s perspective, and precautions are taken such as XML firewalls, to reduce the risk false positives of web service based attacks.

Due to that, a pen tester has to face a lot of problems while conducting web service penetration testing. But there are still certain tools which help to automate web service penetration testing, and we will go through each of them in this article.

The first tool we’re going to use specializes in web services. As I think most of you now have guessed, it’s SoapUI by SMARTBEAR (http://www.soapui.org).

SoapUI is the only popular tool available to test for soap vulnerabilities. But to automate the test, we need to use SoapUI Pro. SoapUI comes in two versions. The first is SoapUI (open source), the second is SoapUI Pro (the commercial version). There is a huge difference between these two tools. The main advantage of SoapUI Pro over SoapUI is that it’s able to automate a security test. SMARTBEAR also provides a fourteen day free evaluation of SoapUI Pro.

SoapUI Pro

We will test the web services behind http://www.testfire.net/bank/ws.asmx?WSDL by using SoapUI Pro. To automate a test, first we need to open our SoapUI Pro tool. Then click on Files, New SoapUI Project. It will open a window as shown below.

Img1: New SoapUI Project window

In this case, we’re testing the web services of testfire. I will use testfire as the project name, and I will use a WSDL URL for testing. As you can see, the Create Requests option is enabled by default under New SoapUI project. That allows SoapUI Pro to extract all the functions and their requests individually from WSDL.

We can start a test with the default settings, but as we’re focusing on automated testing, its better to enable Create TestSuite.

Img2: New soapUI project window with selected options

After that, click on OK to load all the definitions from WSDL. After loading the definitions, a new Generate TestSuite pop-up window will appear. That’s because we’ve enabled the Create TestSuite option.

Img3: Generate TestSuite Window

If you want to play with the options, do so. But, let’s leave it just like that and click on OK. When you will click on OK, you’ll be prompted by another window to enter name of the test suite.

Img4: Enter name for TestSuitewindowE

Give it a name, and click on OK. These two Generate TestSuite steps will continue according to the number of services present in WSDL. In our case, two services are present in WSDL. The first is “Services soap.” The second is “Services soap12.” After completing the process, you’re ready to start security testing.

SoapUI Pro also shows you your test suite properties.

Img5: soapUI Pro window

It also allows you to add a property in the property list, as shown below.

Img6: Add property window

SoapUI Pro allows us to see properties in each level, whether it’s for test suite or any operation test case, or request level.

Now, before we automate the security test, we must understand the request we are going to use for this. Let’s say we’ll test the ServiceSoapTestsuite service and in there we are interested testing GetUserAccountsTestCase. Click on GetUserAccountsTestCase. You will find test steps, load tests, and security tests.

Click on test steps to find the request used. Then, click on that request to open it in the request editor.

Img7: Form View of request editor

As you can see above, by clicking on the GetUserAccounts request, it opens in a request editor. By default it opens in form view. SoapUI Pro allows us to see a request in four different views; XML, raw, outline and form.

We can change the view any time, by clicking on any of the four tabs present in the top left corner of the request editor. Along with that, SoapUI Pro also shows the request property in the bottom-left corner of the window.

You can use any view you want for testing, but for better understanding, we will go for the xml view. By clicking on the XML view, you will get the XML of the GetUserAccounts request.

Img8: Xml view of request editor window

So, as we discussed in our previous article in the “SimpleObject Access Protocol (SOAP)” section, the entire SOAP message is packed in a SOAP envelope which contains a SOAP header and a SOAP body. The most important thing, from a security tester’s point of view, is the value of the “UserId” parameter.

So to test the request, we must provide a value with the required data type in place of the “?” symbol. Generally, we must fuzz this parameter with different types of values of the required data type, to check the result. Also, we can look at other data type values to check the proper implementation of input validation. That’s usually done in manual testing. We’ll focus on that in the next part of the article.

It’s simple to find the required data type of a parameter. You can find required data type information from the form view.

Img9: Form view

Enter any integer value in the XML view to replace the “?” symbol. Click on the green arrow mark on the top left corner of the request editor window to submit a request to the specified endpoint URL. You’ll find a response in the next window.

Img10: Xml view

The XML response in the response window doesn’t contain an error message. That means we executed the GetUserAccounts request properly.

Automation of a Security Test

To automate a security test, first we need to create a new security test. To create a new security test, right click on security test, under the Services Soap Testsuite. Click on new security test and a new window will open.

Img11: Create new Security test window

The new window comes with a name option. Type in any name you want. Under this setup, the three options are Empty Test (add a test with no preconfigurations), automatic (generates default set of security scans) and Full control (to customize your test options.)

As we want to automate the security test, we can choose any option between automatic and full control. When choosing the automatic option, it will test for each and every vulnerability present in its checklist. Its checklist contains nine types of security scans.

1. Boundary scan
2. Cross site scripting
3. Fuzzing scan
4. Invalid Types
5. Malformed XML
6. Malicious Attachment
7. SQL Injection
8. XML Bomb
9. Xpath Injection

Usually, if you’re doing black box testing, and you don’t know the function of a web services request, then it’s better to choose the automatic option and run all the scans blindly. But if you’re doing grey box testing, or you have an understanding of the function used, then it’s better to opt for full control to customize your test, which will save a lot of time.

Here, I’ll use the full control option to demonstrate how to choose options and why you should. Click on the full control option, and click on next. A new window will open.

Img12: Security scans tab

You’ll see two options. Choose the first one to select the same scan, or the second for different security scans for each test step. Use the default for the first option. In select scans, you can select the scans you think the request might vulnerable to. You can select all of them, but it’ll be very time consuming. So select only SQL Injection, and click on next. You’ll go to the parameters tab.

Img13: Parameters tab

By default, SoapUI Pro will extract all the parameters. You can extract parameters by selecting the second option and choosing them from the TestSteps dropdown window.

Img14: Parameters options

SoapUI Pro also allows you to add any parameter, and remove any parameter from the list. Click on next to open the Assertions tab.

Img15: Assertions tab

That tab is most useful in grey box testing. By checking the sample requests, we can add some data or pattern which is sensitive. If in any test, SoapUI Pro finds the same value in response, it will generate an error to avoid the disclosure of sensitive information. In our case, choose select for each Security Scan option, and select Sensitive Information exposure.

Img16: options

Click on next to move to the confirmation tab, where all the options we selected are shown in a table.

Img17: Summary

Then, click on finish to open a new window to start an automated test.

Img18: Security test window

We’ve selected only the SQL Injection test for the GetUserDetails request as it appears in the security test screen. Click on the green arrow button in the top left corner to start an automated test.

After completing the test, the window will look like the image below.

Img19: Security test results

As you can see from the above image, there’s no alert triggered, as there’s no sensitive information in any of the responses which come while using different payloads. Click any request to view the request and its response.

Img20: Sample Request

Img21: Sample Response

When the test is complete, you need a report. SoapUI provides a feature to create a report of the test, by clicking on the create a report for this item button, which is present at the top.

Img22: Report Generation option

Sometimes, you need the log to store as a proof of the test. SoapUI Pro also provides the option to store the log, by clicking on exports the log to a file button.

Img23: Save log option

Conclusion:

This is how SoapUI Pro allows us to automate a security test for different requests. There are other tools available in the market to provide automated web service testing. But SoapUI Pro is a specialized web service tool which can be used for functional testing, load testing, security testing and other different types of testing. This tool plays a vital role in testing web services.

Feasibility

To perform web services penetration testing, soapUI Pro is one of the best options, but in certain conditions you might search for other options: For example, you are not into regular web services penetration testing. or your budget is very low for a penetration testing that consists of web application penetration testing along with web services penetration testing, or you don’t have much experience in performing web services penetration testing.

For these conditions, you need something that comes as a package. A tool for web application penetration testing as well as web services penetration testing. A tool where you just click next, next, next, and it will provide you the result of web services penetration testing. A tool where you can throw the WSDL and get the result. You might choose one of these very popular web application penetrations testing tools, IBM AppScan or HP WebInspect.

AppScan

IBM Security AppScan (http://www-03.ibm.com/software/products/us/en/appscan/) is one of the most popular and widely used automation tools in the arena of web application penetration testing. It allows penetration testers to automate their web application penetration testing to find out the vulnerabilities present in the application. Most penetration testers use it for only web application penetration testing but it can be also used to test web services to identify the vulnerabilities present. Now we will focus on how web services penetration testing is done by IBM Security AppScan.

Testing Web Services Using AppScan

Testing a Web Service using AppScan differs slightly from testing a normal web application because AppScan uses a separate client to explore the web services. That separate client is called the Generic Services Client (GSC).

Generic Service Client (GSC)

It uses the WSDL file of a web service to display the individual methods available in a tree format, and it creates a user-friendly GUI for sending requests to the service. You can use this interface to select methods, one by one, and to input the required values of the parameters. Simultaneously you can also send the request to the server to view the results in the form of the response. These processes are recorded by AppScan and later used to create test cases based on the number of requests made by the GSC for the service.

Configuration

You need to configure AppScan properly with the required options to perform a web services penetration test. As we learned from “Web Services Penetration Testing Parts 1 and 2,” we need a WSDL file or URL to perform web services penetration testing properly. We will test the web services ofhttp://www.testfire.net/bank/ws.asmx?WSDL. It’s always better to have sample test data (SOAP requests and responses) to test web services properly but, since we are performing black box testing, we will provide the format of data needed to perform the testing.

Open AppScan to start the web services penetration testing. AppScan will start with the window shown in Figure 1.

Figure 1: New Window

This window will show the recent scans and the option to “Create New Scan.” Click on that option. The “New Scan” window will open, as shown in Figure 2.

Figure 2: New Scan Window

This “New Scan” window will show the “Recent Templates” used and also option to select one of the “Predefined Templates.” Select “Regular Scan” from the “Predefined Templates.” By clicking on the “Regular Scan” template, the “Scan Configuration Wizard” window will open, as shown in Figure 3.

Figure 3: Scan Configuration Window

In the “Scan Configuration Wizard,” select “Web Services Scan” and click on “Next” to open a window where you need to provide the WSDL file or WSDL URL, as shown in Figure 4.

Figure 4: URL and Servers Window

If you need to configure any additional settings for proxy or HTTP authentication, you can configure them here, but to test the web services, I will continue with the default settings, as shown in Figure 5.

Figure 5: URL and Servers Window

Click on “Next” to open the “Test Policy” window, as shown in Figure 6.

Figure 6: Test Policy Window

Here you will find a predefined policy present to test SOAP-related tests, i.e., “Web Services.” Select “Web Services.” If you want to check what are the test cases associated with this policy, just click on the “Full Scan Configuration” link, which is in the left bottom corner of this window, under “General Tasks.” Clicking on the “Full Scan Configuration” link will open a new “Full Scan Configuration” window, as shown in Figure 7.

Figure 7: Full Scan Configuration Window

Select the “Test Policy” tab, which is on the left side of the window under “TEST,” to view the test cases included in this Web Services policy. Under the “No Grouping” option when you start exploring the test cases, you will see three types of buttons:

1. Disabled
2. Enabled
3. Partially Enabled

Below mentioned are some of the classes of test cases included in this policy.

1. XML External Entities
2. Information Leakage
3. Insufficient Authentication
4. SQL Injection
5. Cross Site Scripting
6. Directory Indexing
7. Abuse of functionality
8. Session Fixation
9. OS Commanding
10. Format String
11. Brute Force
12. Insecure Indexing
13. LDAP Injection
14. Content Spoofing
15. Remote File Inclusion
16. Null Byte Injection
17. SSI Injection
18. Insufficient Session Expiration
19. Insufficient Transport Layer Protection
20. HTTP Response Splitting
21. Path Traversal
22. XPath Injection

After exploring the test cases included, click on “OK” to close the full scan configuration window, then click on “Next” to complete the configuration wizard and it will open a new window, as shown in Figure 9.

Figure 9: Complete Scan Configuration Window

This window shows that you have successfully completed the scan configuration wizard and also provides information how to start the test by exploring web services methods using GSC. Click on “Finish” to launch GSC, where GSC will import all the methods available in the provided WSDL file as shown in Figure 10.

Figure 10: GSC Window

This GSC shows all the imported methods under “Request Library.” Now you need to edit each method request and provide a value for the required parameter with the required data type in the edit request option, as shown in Figure 11.

Figure 11: GSC

I selected the “IsValidUSer” method and clicked on the “UserId” parameter. It requires a string datatype value. Now provide a string datatype value and invoke the request. I provided the value 1 and clicked on the “Invoke” button; the response I got is shown in Figure 12.

Figure 12: GSC Request Editor

Similarly select all the methods, put the required data type value in the parameters, and invoke the requests one by one. After completion of all the invocation of requests, close the GSC window. Now AppScan will record all the requests and generate the test cases to start web services penetration testing, as shown in Figure 13.

Figure 13: AppScan Test Window

As you can see, AppScan fetched all the requests from GSC request history and is all set to start the test. Just click on the “Test Only” option in the top left corner to start the test. After completion of all test cases, you will get the result in AppScan, as shown in Figure 14.

Figure 14: AppScan Result

Here are the results of the web service scan using AppScan. Now you can use AppScan to test any web service to discover the vulnerabilities present. And you need to verify it manually to avoid False-positive.

WebInspect

HP WebInspect (http://www8.hp.com/in/en/software-solutions/software.html?compURI=1341991) is another very popular tool for web application penetration testing. It uses real-world hacking techniques and attacks to thoroughly analyze your web applications and web services to identify security vulnerabilities. It contains some features in web services penetration testing that make it one of the popular black box web services penetration testing tools. Now we will focus on how to test web services using HP WebInspect.

Open WebInspect and you will find its start page containing “Recently Opened Scans,” “Scans Scheduled for Today,” “WebInspect Messages,” “What’s new in WebInspectxx.x!” (where “xx.x” is the version of WebInspect you are using), along with options to start a new scan, as shown in Figure 15.

Figure 15: WebInspect Start Page

Click on “Start a Web Service Scan,” which will open a “Web Service Scan Wizard,” as shown in Figure 16.

Figure 16: Web Service Scan Window

Select “Configure a Web Service Scan” and in the space for “WSDL Location” insert your WSDL URL. In my case, I am using the samehttp://www.testfire.net/bank/ws.asmx?WSDL. And in “Scan Name” enter a name. I am using testfire, as shown in Figure 17.

Figure 17: Web Service Scan Window

Click on “Next” to get the “Authentication and Connectivity” window, where you have to provide all the required details, as shown in Figure 18.

Figure 18: Authentication and Connectivity Window

As in our case we don’t need any “Network Proxy” or “Network Authentication,” uncheck the “Network Proxy” option, as shown in Figure 19.

Figure 19: Authentication and Connectivity Window

Click on “Next” to open the next window, which contains “Detailed Scan Configuration” but, before that you will be prompted with a pop-up, “Would you like to launch the Web Service Test Designer Now?”, as shown in Figure 20.

Figure 20: Web Service Test Design Prompt

Click on “Yes” to open a new “Web Services Test Designer” window. This window contains all the methods in the provided WSDL file in the top left corner. If you want to add other methods or want to remove any methods, just check or uncheck that method, as shown in Figure 21.

Figure 21: Web Service Test Designer Window

I mentioned earlier that WebInspect is a popular black box web services testing tool and here is the reason: It not only imports all the methods from the WSDL but also fills in the values of required data types in the parameter. So, as a pen tester, you just need to provide a valid WSDL to WebInspect and it will do the rest of the things for you, unlike the other tools, where you need to manually insert data in each method. There is one limitation: Sometimes WebInspect is unable to fill in the proper data type in a required parameter and is unable to detect that method. In our case, WebInspect is unable to detect the IsValidUser method, so a red cross is displayed at the right side of that method.

Now close the “Web Services Test Designer” window. It will prompt you to save the designer file. Click on “Yes” and save it by providing a name for your test designer file in your computer. I saved it as test4. And you will get the name auto set in the names field in Detailed Scan Configuration window as shown in Figure 22.

Figure 22: Detailed Scan Configuration Window

You can see other settings in the same window. If you want any customized settings, you can enable them but, in this case, I am proceeding with the default settings. Click on “Next” to complete the wizard, as shown in Figure 23.

Figure 23: Web Services Scan Wizard Final Window

You will get a congratulation message there. Now click on “Scan” to start the scan. WebInspect will scan the web service and provide you with the vulnerability report, as shown in Figure 24.

Figure 24: WebInspect Result

Here the results of the web service scan are displayed. Now you can use WebInspect to test any web service, especially black box, to discover the existing vulnerabilities and you need to verify it manually to avoid false-positives.

Conclusion

Any automated tool will help you to get good results from a penetration testing and will reduce your time and effort, but it’s always better to use them just for coverage and focus more on manual testing, because automated tools can provide false positives and false negatives as well.

Manual Testing

Manual testing covers lots more different types of nontraditional test cases that will help a pen tester to understand the functionalities and trying different new approaches based on the scenario, rather than fuzzing the general payloads to cover traditional vulnerabilities. It allows a pen tester to think out of the box, which may lead to a zero-day. It also provides freedom to a pen tester to test different business logic vulnerabilities that are literally impossible to cover by a auto scanner.

For manual testing also we need some kind of tools that will help us, so today we will start with the open source manual tools that can be used test web services. We will start with a simple yet effective Mozilla Firefox add-on, SOA Client.

SOA Client

SOA Client (https://addons.mozilla.org/en-US/firefox/addon/soa-client/) is a Mozilla Firefox add-on by Michael Santoso. It is a portable client to access web services and UDDI registries. It is easy to install and it has a user-friendly interface to perform web services penetration testing manually, as shown in Figure 1.

Figure 1: SOA Client window

As I stated earlier, SOA Client is used to access WSDL and UDDI. Below is a list of some web services and UDDI registries that are on the SOA Client page.

Web Services

Credit card verification: https://ws.cdyne.com/creditcardverify/luhnchecker.asmx?wsdl
Census information:http://ws.cdyne.com/DemographixWS/DemographixQuery.asmx?wsdl
Currency foreign exchange: http://www.xignite.com/xCurrencies.asmx?WSDL
Email address validation: http://www.webservicex.com/ValidateEmail.asmx?WSDL
English dictionary: http://services.aonaware.com/DictService/DictService.asmx?WSDL
Number conversion:http://www.dataaccess.com/webservicesserver/numberconversion.wso?WSDL
Image converter (e.g., PSD into JPG):http://www.bigislandcolor.com/imageconvert.wsdl
IP address into location: http://ws.cdyne.com/ip2geo/ip2geo.asmx?wsdl
Stock quote: http://ws.cdyne.com/delayedstockquote/delayedstockquote.asmx?wsdl
Translator (English to Chinese):http://fy.webxml.com.cn/webservices/EnglishChinese.asmx?wsdl
FIFA World Cup 2010: http://footballpool.dataaccess.eu/data/info.wso?WSDL
Weather forecast: http://www.webservicex.net/WeatherForecast.asmx?WSDL

UDDI Registries

http://hma.eoportal.org/juddi/inquiry
http://registry.gbif.net/uddi/inquiry
http://test.uddi.microsoft.com/inquire

As you can see in Figure 1, There are four tabs in SOA Client:

1. Access Web Services
2. Access UDDI Registries
3. Advanced Access
4. About

In this article, we will be using mostly the “Access Web services” and “Advanced Access” options, since we are going to use a public-facing demo web service and not the UDDI registry. So, for this case, we are going to use the same (http://www.testfire.net/bank/ws.asmx?WSDL) for manual testing.

Manual Testing with SOA Client

First open your SOA Client and put this WSDL URL, as shown in Figure 2.

Figure 2: Access Web Services tab

Then Click on “Parse WSDL” to import all the operations present in that web service, as shown in Figure 3.

Figure 3: Parsed WSDL window

In the result page, you will get all the operations available in the web service. And, as you can see, there are five tabs:

1. Raw WSDL Data
2. Raw Request Header
3. Raw Request Body
4. Raw Response Header
5. Raw Response Body

This is a very good, light-weight, simple GUI tool to test web services manually. Let’s start the test by selecting the “GetUserAccounts” operation, as shown in Figure 4.

Figure 4: invoking GetUserAccounts operation

As we can see here, the “GetUserAccounts” operation contains only one parameter of “int” data type and we provided an appropriate value there. Now click on “Invoke” (because Figure 4 is a partial image, you will see the “Invoke” button on the very right side of this window. as shown in Figure 3) to send the request.

Since we provided it with a proper request, we get a valid response “200 OK” without any error. (If you remember, in the previous article “Web Services Penetration Testing, Part 2: An Automated Approach With SoapUI Pro” in Figure 10: XML View, we used the same method and value and got a response with no error; here we got a similar response, as shown in Figure 5.)

Figure 5: Response to GetUserAccounts requests

Similarly, you can change the values in different parameters and invoke the request to get the response. But there are certain problems with this SOA Client; one problem is that sometimes it won’t parse the WSDL properly. That’s what happened here. As you can see in Figure 6 in the Raw WSDL Data tab, the operation “TransferBalance” has four parameters, but in the GUI, the SOA Client shows only two.

Figure 6: Parsed WSDL operations window

As is very clear from the raw WSDL data, the “TransferBalance” operation needs four values:

1. transferDate (date-time data type)
2. debitAccount (string data type)
3. creditAccount (string data type)
4. transferAmount (double data type)

But the SOA Client only parsed two parameters, “debitAccount” and “creditAccount.”

We can come out of this and still perform web service manual penetration testing using its “Advanced Access” option. All we need is the sample request. Most probably, in gray box testing, we are provided with sample requests, but sometimes we get those sample requests due to an information leakage vulnerability.

I prefer this tool when I get a WSDL file and the sample requests are disclosed publicly due to server misconfiguration while performing a Web application penetration test. I use the “Advanced Access” module to check the operation to find vulnerabilities.

So here we assume that we found the sample requests of this WSDL (http://www.testfire.net/bank/ws.asmx?WSDL) and we use them to learn how to use the “Advanced Access” module in the SOA Client tool.

We will use the sample request of the “TransferBalance” operation, which can be found on (http://www.testfire.net/bank/ws.asmx?op=TransferBalance), as shown in Figure 7. The normal “Access Web Services” module is unable to parse it properly.

Figure 7: Sample request for the TransferBalance operation

Before starting the testing, first let’s have a check on the “Advanced Access” module interface to understand what data we need to start the test. The interface can be found in Figure 8.

Figure 8: Advanced Access module window

As you can see, we need a URL (which is an end point URL to perform the test). We have to specify the request type (whether we want to use GET, POST, HEADER, TRACE, or OPTIONS). We have to deal with the authentication mechanism, if any is needed, and we need to determine the communication type, synchronized or asynchronized. We also need the HTTP request header (If any specific header has to be added) and, last but not least, the SOAP request. We can find all these details in the sample request. But before that, we need to understand how to differentiate all these requirements from that one sample request, as shown in Figure 9.

POST /bank/ws.asmx HTTP/1.1
Host: www.testfire.net
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://www.altoromutual.com/bank/ws/TransferBalance"

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

dateTime string
string
double

Figure 9: Sample request of TransferBalance operation

This is the same request from Figure 7. Here we can see in the very first line that the request method is POST. And from line 1 and line 2 we can deduce that the URL used must be http://www.testfire.net/bank/ws.asmx. In the header there is nothing special that we need to use in the “Advanced Access” module. The type of communication is not specified, so we can go with the default options. There is no authentication mechanism required for this request, so we will not touch that option in the “Advanced Access” module. And last but not least, we have the SOAP request in the second part of the sample request. This SOAP request contains four parameters.

1. transferDate (date-time data type)
2. debitAccount (string data type)
3. creditAccount (string data type)
4. transferAmount (double data type)

As it’s a black box testing, we don’t have the exact data that we can use in this request, so we will use some data with the required data type.

1. transferDate (date-time data type) = 2009-01-01T00:00:00
2. debitAccount (string data type) = test
3. creditAccount (string data type) = tester
4. transferAmount (double data type)= 1.0

When we enter all these details in the “Advanced Access” module it will look as shown in Figure 10.

Figure 10: Advanced Access window with required data

The things added or changed are marked in red in Figure 10. The rest are the default settings. Now submit the request by clicking the “Submit” button in the right top corner to get a response. The response is shown in Figure 11.

Figure 11: Response of TransferBalance request

As you can see in Figure 11, in the “Raw Response Body” tab we got the “200 OK” with some interesting information.

1. TransferBalanceResult success is false (we are unable to transfer the balance).
2. System.Data.OleDb.OleDbException (we got a “DB Exception”; this is a hint to a possible SQLI).
3. d:\downloads\AltoroMutual_v6\website\App_Code\WebService.cs:line 146 (server path disclosure).

This is how we can use the “Advanced Access” module of the SOA Client tool. This is how we manually test for various vulnerabilities. As we can see, by using one request we got one vulnerability, the server path disclosure, and a hint of another vulnerability, i.e., SQLI. One/some/all of the parameters might be vulnerable to SQLI; you just need to check each of the parameter to get the result.

What we have learned so far is how to use different modules of SOA Client to perform the manual web service penetration testing. There are restrictions, such as the fact that it sometimes won’t able to parse the request properly and, to test efficiently, we need the sample request.

Conclusion

Although there are certain limitations, SOA Client is a very light-weight and user-friendly GUI tool. We can use it in most of the cases while performing the penetration testing of web services. But there are certain cases where we are bound to choose another option.

Let’s say we need to perform a black box web services penetration testing: In that case, there is no way we will get the sample request from the client. What if the sample request is not exposed to public as it is exposed in our case for testfire.net? What if SOA Client is unable to parse some requests, as we see earlier in this article? We need some other tool to perform manual web services penetration testing and we will learn about that in the next installment.

References

https://addons.mozilla.org/en-US/firefox/addon/soa-client/

https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcT0Nhftsh09x8FvWR14QfK2tIsdTf6R3akw0uB-9cuHVeyGWFnA7g

http://www-03.ibm.com/software/products/us/en/appscan/

http://www-01.ibm.com/support/docview.wss?uid=swg21404788

http://pic.dhe.ibm.com/infocenter/apsshelp/v8r6m0/index.jsp?topic=%2Fcom.ibm.help.common.infocenter.aps%2Fc_WebApplicationsvsWebServices002.html

http://www8.hp.com/in/en/software-solutions/software.html?compURI=1341991

http://h30499.www3.hp.com/t5/WebInspect/Using-WebInspect-9-10-to-scan-a-web-service/td-p/4817387

http://blog.qatestlab.com/wp-content/uploads/2013/09/software-testing-company-000188.png

http://www.soapui.org/

http://www.techrepublic.com/blog/software-engineer/how-to-test-web-services-with-soapui/

http://www.techrepublic.com/blog/programming-and-development/easily-test-web-services-with-soapui/699

http://cdn.softwaretestinghelp.com/wp-content/qa/uploads/2006/12/Automated-Testing.png

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/

Fuentes:

http://resources.infosecinstitute.com/web-services-penetration-testing-part-1/

http://resources.infosecinstitute.com/web-services-penetration-testing-part-2-automated-approach-soapui-pro/

http://resources.infosecinstitute.com/web-services-pen-test-part-3-automation-appscan-webinspect/

http://resources.infosecinstitute.com/web-services-pen-test-part-4-manual-testing-soa-client/