Web Services Penetration Testing Part 3: Automation with AppScan and Webinspect

In the previous article, we discussed the importance of tools in penetration testing, how automation helps in reducing time and effort, and how to automate web services penetration testing using soapUI Pro.
In this article, we will be focusing on what other options are available to automate web services penetration testing.
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 of http://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 same http://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.

Want to learn more?? The InfoSec Institute Ethical Hacking course goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises. While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to black hat hackers. Some features of this course include:

• Dual Certification - CEH and CPT
• 5 days of Intensive Hands-On Labs
• Expert Instruction
• CTF exercises in the evening
• Most up-to-date proprietary courseware available

VIEW ETHICAL HACKING

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

Xem thêm...

Web Services Penetration Testing, Part 2: An Automated Approach With SoapUI Pro

In the previous article, we discussed how the sudden increase in the use of web services makes it an important attack vector. Also, we covered different components of web services, different elements of WSDL, their uses, where to start, and how to perform penetration testing.
In this article we will be focusing more on automated tools available for web service penetration testing.
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.

Want to learn more?? The InfoSec Institute Web Application Penetration Testing Boot Camp focuses on preparing you for the real world of Web App Pen Testing through extensive lab exercises, thought provoking lectures led by an expert instructor. We review of the entire body of knowledge as it pertains to web application pen testing through a high-energy seminar approach.

The Web Application Penetration Testing course from InfoSec Institute is a totally hands-on learning experience. From the first day to the last day, you will learn the ins and outs of Web App Pen Testing by attending thought provoking lectures led by an expert instructor. Every lecture is directly followed up by a comprehensive lab exercise (we also set up and provide lab workstations so you don't waste valuable class time installing tools and apps). Benefits to you are:

• Get CWAPT Certified
• Learn the Secrets of Web App Pen Testing in a totally hands-on classroom environment
• Learn how to exploit and defend real-world web apps: not just silly sample code
• Complete the 83 Step "Web App Pen Test Methodology", and bring a copy back to work with you
• Learn how perform OWASP Top 10 Assessments: for PCI DSS compliance

VIEW WEB APP PEN TEST

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

Xem thêm...

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.

1. POST /ws/ws.asmx HTTP/1.1
2. Host: www.example.com
3. Content-Type: text/xml; charset=utf-8
4. Content-Length: length
5. SOAPAction: "http://www.example.com/ws/IsValidUser"
6. 
   
7. <?xml version="1.0" encoding="utf-8"?>
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/">
9. <soap:Body>
10. <IsValidUser xmlns="http://www.example.com/ws/">
11. <UserId>string</UserId>
12. </IsValidUser>
13. </soap:Body>
14. </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. HTTP/1.1 200 OK
2. Content-Type: text/xml; charset=utf-8
3. Content-Length: length
4. 
   
5. <?xml version="1.0" encoding="utf-8"?>
6. <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/">
7. <soap:Body>
8. <IsValidUserResponse xmlns="http://www.example.com/ws/">
9. <IsValidUserResult>boolean</IsValidUserResult>
10. </IsValidUserResponse>
11. </soap:Body>
12. </soap:Envelope>

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.

Elements	What it contains
definitions	All the XML elements are packed under definition element. It is also called a root or parent element of the WSDL file.
types	All the schema types or data types are defined here.
message	This is a dependent element. Message is specified according to the data types defined in types element and used in side operation 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)

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.

Want to learn more?? The InfoSec Institute Web Application Penetration Testing Boot Camp focuses on preparing you for the real world of Web App Pen Testing through extensive lab exercises, thought provoking lectures led by an expert instructor. We review of the entire body of knowledge as it pertains to web application pen testing through a high-energy seminar approach.

The Web Application Penetration Testing course from InfoSec Institute is a totally hands-on learning experience. From the first day to the last day, you will learn the ins and outs of Web App Pen Testing by attending thought provoking lectures led by an expert instructor. Every lecture is directly followed up by a comprehensive lab exercise (we also set up and provide lab workstations so you don't waste valuable class time installing tools and apps). Benefits to you are:

•  
• Learn the Secrets of Web App Pen Testing in a totally hands-on classroom environment
• Learn how to exploit and defend real-world web apps: not just silly sample code
• Complete the 83 Step "Web App Pen Test Methodology", and bring a copy back to work with you
• Learn how perform OWASP Top 10 Assessments: for PCI DSS compliance

 

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/

Xem thêm...