Web Services Enumeration and Manipulation

The Most Powerful All-in-one SEO Tool Suite

Search Engine Traffic Guide

Get Instant Access







Risk Rating:


In earlier implementations of web services, an organization would register their web service with a Universal Business Registry (UBR) so that third parties could search a master Universal Description, Discovery and Integration (UDDI) database of publicly available e-commerce web services. Attackers could also search these public databases to discover web services, and all of the information required to access them, via a Web Services Definition File (WSDL) file.

The modern architecture of web services has migrated away from this public system since most of today's web services are only intended for private use within organizations or among trusted business partners. In January 2006, IBM, Microsoft, and SAP announced that they were closing their public UDDI databases, signaling the end of this original architecture.

Getting your hands on the WSDL file is the first step in hacking a web service. This XML-formatted document defines the methods on how to interact with the web service, the arguments and types required, as well as where the service is located. From here, an attacker knows where and how to use the web service and can, therefore, start performing the same attacks that are described throughout this chapter.

So, how do you find the WSDL file for the target organization now that public UBRs are no longer available? The WSDL file can be accessed either via a file with a .wsdl extension directly or via a parameter to a web application program, as shown here:

http://webservices.example.com/MyWebService.wsdl http://webservices.example.com/webservice.php7wsdl

The simplest way of finding this file for an organization, if you are lucky, is by using the advanced options in a search engine. In Google you can use either of the following search terms. An example is shown in Figure 13-7.

site:example.com filetype:wsdl site:example.com inurl:wsdl

This requires that the organization has either made the WSDL file available for a public web service or accidentally leaked the file onto the Internet due to weak ACLs, where search engines and attackers can find it. You could also find this file by crawling an organization's web application to determine whether a link exists to the WSDL file, as well as by brute-forcing common WSDL-related filenames and directories, or by appending the 7wsdl parameter to the end of each web application program.

Figure 13-7 Using Google to enumerate WSDL files for Microsoft

Figure 13-8 demonstrates a WSDL file that provides the functionality to search for multiple names within an example web service. Understanding the key sections of a WSDL file is critical when hacking a web service. The types section defines the format of the available methods, including the corresponding parameters and types. The SearchRequest method requires two elements, Name and Count of type String and Integer, respectively. The message sections define the method names and types, such as input or output, which correspond to request and response. The service section defines the web service name and the address where the web service is located. This is the URL used to actually access the web service. The other item to note is the definitions sections, which contains links to Simple Object Access Protocol (SOAP) schemas that can be used throughout the WSDL file.

A request to a web service is performed by issuing a POST request, with the POST data containing XML-formatted data based on the WSDL file specifications that have been enumerated. Figure 13-9 demonstrates the POST data for a request to the example web service that was enumerated in Figure 13-8.

This request may require additional information based on the SOAP definitions throughout the WSDL file. Once you have successfully made a request to the web service, then you can finally begin to test out the security controls that have been implemented within the web service. A web service can be vulnerable to any web application vulnerability that we discuss throughout this chapter, including cross-site scripting, SQL

¿■?xml wfirsmn-"1 .n* pnr.nriing—"UTF-fl" ?">

<wsdl: definitions name="Ueorch" xmln5="http://schemos.xmlsoap,Drg/wsdl/" xmln5:saap=,,http://5chemas.xmlsoap,Drg/v\isdl/soap/' xmlns: wsdl-"http://schomas.Mmlsoap.org/wsdl/" xmlns: xsd-'http://www.w3.org/2001/XMLSchema" targfitNflmpsparp='http://vifihsfirvines.exnmplfi.nnm'1 :<imtns:tns=,http://vifihsfirvinfis.fixnmplfi.nnm'l"i-

- c:xsd:schema xmlns:xsd—"http://w%"fvj.w3.org/2001/XMLSchemo" xmlns-"httpr/Zweb services,example.com1

targetNamespace='http://webservices.example,com' at tributerormDetault='unqualified" elementrormDetault='quQlitiedr>

- <.xtd: ulyrritfriL i idrr w_";tUtiridiRui|uusl',.> - *:xsd:r.nmplfixTypfl>

<x£d:element name-'Name" type-"xsd: string" /> <xtd:iilyrHyriL ridiiiy="Conril" typy="xsd:inl"/> </xsri: seqijfinrfi> </xsd: complcxTypo </xbd; y|yrnanl>

- vx^ri: fitfinifint nflmf=!-"«iF!rHT-hRfispnrisF!">

<xsd:complox I ypo

<:xsd:element name—"searchResult1 type—"xsd:stnng" /:» </xsd:sequence> </xsd: complcxTypo </xi»d: yl«rn«iil.^ v/xsrl: sr.hRma> </wsdl:typcs> + <.wbdl;iiiw!»td4w ridiiiw-ubUcjn;hRuqu«!»t'? + <wsdl: message name—"se arch Response";: + <wsdi:port I ype name=,UearchHortt ype*>

+ <w£dl:binding name-'SearchSaapBltidlng" type-"tns:SoarchPortTvpo">

- iwsril;pnrt nflme="fienrrhPnrt1 hinrling=',tns:iifint,rhiinnpninr1mg,v

<aoop: ad dross lacot ion=' http://webs c rvi co .example .com: /01 l/s c rvicc s/soarch" />

<wiwd;UtiiiqAdUrutiinn KHilrii:wiwd-1"hU[j;//*,#ww.»v3.uri|/2005/08/<iddrH;>iiriif/v#sUr /> c/w^rii: port j

</wsdl:service> </wsdl: definitions

Figure 13-8 Example WSDL file for a Name Search web service injection, default errors, cross-site request forgery, insecure cookies, weak SSL versions and ciphers, and so on. Web services also introduce a number of new attacks that are not present in generic web applications. These attacks become present due to the use of XML within the web application or service.

Since it takes a lot more resources on the receiving server to parse and process an XML request than it does to simply send a request from the client, attackers can cause a denial of service (DoS) attack by sending an extremely large XML request. A similar attack, known as the entity expansion attack, can trigger a DoS by defining some recursive

<?xml ver£ion="l.G" encoding="UTF-8" ?>

<Envelope xinfns;SOAPS-"http;//*vww.w3.org/20Dl/XML3chemo' xmlns; SOAPI-"http://www.w3.org/2001/XML3chemo-fnstonce' xmlns; £OAPN="http://schomas .xmtsoap.org/saap/oncodtng/" xmlns; £QAPE="http://schcmas.nmlsoap.org/soap/cnvoIopo/">

< NnrriH slnhric/NniriH > <Coun t >l</Cou nt> </se archkeque £ t > </RniJy> </Envelope>

Figure 13-9 post data for a request to the Name Search web service entity declarations that point back to themselves, causing the server to slip into expanding the defined entity endlessly, resulting in the system resources being consumed.

By declaring an entity that points to a local file, the server may attempt to expand the entity that allows an attacker to probe for files that exist on the server, possibly allowing the filename or file contents to be returned to the user via an XML-formatted error message.

Was this article helpful?

0 0
SEO Made Easy

SEO Made Easy

Discover How To Get Your Sites On Top of The Search Engines So You Can Generate More Leads and Sales, Introducing... SEO Made Easy'. You'll discover why search engine optimization is important and why you should be optimizing are your pages so people can find your site.

Get My Free Ebook

Post a comment