This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Testing: WS Information Gathering (OWASP-WS-001)
OWASP Testing Guide v3 Table of Contents
This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.
OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here
Brief Summary
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.
Black Box Testing and example
Zero Knowledge
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:
inurl:wsdl site:example.com
and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service.
WSDL endpoints
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:
http://www.example.com/ws/FindIP.asmx?WSDL
you can obtain the following description of the Web Services:
<?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:types> <s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/"> <s:element name="GetURLIP"> <s:complexType> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" /> </s:sequence> </s:complexType> </s:element> <s:element name="GetURLIPResponse"> <s:complexType> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" /> </s:sequence> </s:complexType> </s:element> <s:element name="string" nillable="true" type="s:string" /> </s:schema> </wsdl:types> <wsdl:message name="GetURLIPSoapIn"> <wsdl:part name="parameters" element="tns:GetURLIP" /> </wsdl:message> <wsdl:message name="GetURLIPSoapOut"> <wsdl:part name="parameters" element="tns:GetURLIPResponse" /> </wsdl:message> <wsdl:message name="GetURLIPHttpGetIn"> <wsdl:part name="EnterURL" type="s:string" /> …… </wsdl:service> </wsdl:definitions>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input. In that manner we have identified the WS entry point and we are ready to test it.
References
Tools
- Net Square wsPawn
- OWASP WebScarab: Web Services plugin