What Is A Web Service?
| | ||
Simply stated, a web service is a self-contained software component that performs specific functions and publishes information about its capabilities to other components over a network. Web services are based on a set of much-hyped Internet standards-in-development, including the Web Services Definition Language (WSDL), an XML format for describing the connection points exported by a service; the Universal Description, Discovery, and Integration (UDDI) specification, a set of XML protocols and an infrastructure for the description and discovery of web services; and the Simple Object Access Protocol (SOAP), an XML-based protocol for messaging and RPC-style communication between web services. Leveraging these three technologies, web services can be mixed and matched to create innovative applications, processes, and value chains.
| Note | You probably noted the centrality of the eXtensible Markup Language (XML) within web services technologiesbecause of the ease with which XML represents data in a structured fashion, it provides a strong backbone for interapplication communication. For this reason, web services are often referred to as XML web services, although technically XML is not required to implement them. |
Even more appealing, web services offer a coherent mechanism for alleviating the typically arduous task of integrating multiple web applications, coordinating standards to pass data, protocols, platforms, and so on. Web services can describe their own functionality and search out and dynamically interact with other web services via WSDL, UDDI, and SOAP. Web services thus provide a means for different organizations to connect their applications with one another to conduct dynamic e-business across a network, no matter what their application, design, or run-time environment (ASP.NET, ISAPI, COM, PHP, J2EE, and so on).
What distinguishes web services from plain old web sites? Web services are targeted at unintelligent agents rather than end users. As Microsoft puts it, "In contrast to web sites, browser-based interactions, or platform-dependent technologies, web services are services offered computer-to-computer, via defined formats and protocols, in a platform-independent and language-neutral manner."
Figure 8-1 illustrates how web services integrate into the typical web application architecture we described in Chapter 1 (we've omitted some of the details from the original drawing to focus on clarifying the role of web services). Figure 8-1 shows a web service at hypothetical Company A that publishes information about Company A's applications to other companies (hypothetical Company B) and Internet clients . Let's talk about some of the more important aspects of web services technology in this diagram.
Figure 8-1: A diagram of a stereotypical web services architecture
Transport: Soap Over Http(S)
Web services are transport agnostic , but most current standards documentation discusses HTTP (and MIME for non-ASCII data). Any other Internet-based service could be used (for example, SMTP), and thus, in Figure 8-1, we've wrapped our web services inside of a generic "Server" that mediates communication with web services.
SOAP is encapsulated in whatever transport is usedthe most common example is SOAP over HTTP (or HTTPS, if communications confidentiality and integrity are needed). Recall that SOAP is the messaging protocol used for communication with a web serviceso what types of messages does it carry? According to the World Wide Web Consortium (W3C) SOAP Primer, "SOAP provides the definition of an XML document, which can be used for exchanging structured and typed information between peers in a decentralized, distributed environment. It is fundamentally a stateless, one-way message exchange paradigm" SOAP messages are comprised of three parts : an envelope, a header, and a body, as diagrammed in Figure 8-2.
Figure 8-2: A schematic representation of a SOAP message, showing envelope, body, and headers
At the lowest level of detail, a SOAP message encapsulated over HTTP would look like the following example of a hypothetical stock trading web service (note the envelope, header, body, and subelements within each). Note that the original request is an HTTP POST.
POST /StockTrader HTTP/1.1 Host: www.stocktrader.edu Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <m:quote xmlns:m="http://www.stocktrader.edu/quote" env:actor="http://www.w3.org/2001/12/soap-envelope/actor/next" env:mustUnderstand="true"> <m:reference>uuid:9oe4567w-q345-739r-ba5d-pqff98fe8j7d</reference> <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime> </m:quote> <SOAP-ENV:Body> <m:GetQuote xmlns:m="Some-URI"> <symbol>MSFT</symbol> </m:GetQuote> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
The response to our hypothetical web service request might look something like this:
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:GetQuoteResponse xmlns:m="Some-URI"> <Price>67.5</Price> </m:GetQuoteResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
SOAP Hacking Tools
Although it may look complex at first glance, SOAP over HTTP is just as approachable as any of the other text-based Internet protocolsand potentially as easily manipulated!
Since web services are just XML over HTTP, any HTTP manipulation tool (like those discussed in Chapter 1) will work. But why do all that work when there are excellent tools available for just messing with SOAP? The following list is the authors' choice of available SOAP hacking tools:
-
WebService Studio This is a free tool offered by www.gotdotnet.com and is the one we use most often. By entering a WSDL location, the tool will generate all the available methods and offer an interactive UI for entering data. It will display the raw SOAP request and response that was created for your web service request. It also has some cool features like showing the WSDL in a nice parsed out tree view. Figure 8-3 shows WebServices Studio in action.
Figure 8-3: WebService Studio from www.gotdotnet.com -
WSDigger This a free tool offered by Foundstone that does some very simple automated testing like XPath injection, SQL injection, and command execution against web services. It's not as flexible as WebService Studio, but does contain the ability to print out a nice report showing any vulnerabilities found against the web service. Very useful tool.
-
SoapClient.com SoapClient has a nice web page listing of very useful web service tools such as WSDL validators, WSDL analyzers, SOAP clients, and UDDI browsers. If you need it, you can usually find it here.
WSDL
Although not shown in Figure 8-1, WSDL is central to the concept of web services. Think of it as a core component of a web service itself, the mechanism by which the service publishes or exports information about its interfaces and capabilities. WSDL is typically implemented via one or more pages that can be accessed on the server where the web service resides (typically, these carry .wsdl and .xsd file extensions).
The W3C specification for WSDL describes it as "an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages." In essence, this means a WSDL document describes what functions ("operations") a web service exports and how to connect ("bind") to them. Continuing our example from our previous discussion of SOAP, here is a sample WSDL definition for a simple web service that provides stock trading functionality. Note that our example contains the following key pieces of information about the service:
-
The types and message elements define the format of the messages that can be passed (via embedded XML schema definitions).
-
The portType element defines the semantics of the message passing (for example, request-only, request-response , and response-only).
-
The binding element specifies various encodings over a specified transport such as HTTP, HTTPS, or SMTP.
-
The service element defines the endpoint for the service (a URL).
<?xml version="1.0"?> <definitions name="StockTrader" targetNamespace="http://stocktrader.edu/stockquote.wsdl" xmlns:tns="http://stocktrader.edu/stockquote.wsdl" xmlns:xsd1="http://stocktrader.edu/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <schema targetNamespace="http://stocktrader.edu/ stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="GetQuote"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> <element name="Price"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types> <message name="GetQuoteInput"> <part name="body" element="xsd1:QuoteRequest"/> </message> <message name="GetQuoteOutput"> <part name="body" element="xsd1:StockPrice"/> </message> <portType name="StockQuotePortType"> <operation name="GetQuote"> <input message="tns:GetQuoteInput "/> <output message="tns:GetQuoteOutput "/> </operation> </portType> <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http:// schemas.xmlsoap.org/soap/http"/> <operation name="GetQuote"> <soap:operation soapAction= "http://stocktrader.edu/GetQuote"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="StockQuoteService"> <documentation>User-readable documentation here </documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location= "http://stocktrader.edu/stockquote"/> </port> </service> </definitions>
The information in a WSDL document is typically quite benign , as it is usually intended for public consumption. However, as you can see here, a great deal of business logic can be exposed by WSDL if it is not properly secured. In fact, WSDL documents are often likened to "interface contracts" that describe what terms a particular business is willing to accept in a transaction. Additionally, web developers are notorious for putting inappropriate information in application files like WSDL documents, and we're sure to see a new crop of information disclosure vulnerabilities via this interface.
Directory Services: UDDI And DISCO
As defined by UDDI.org, "Universal Description, Discovery, and Integration (UDDI) is a specification for distributed web-based information registries of web services. UDDI is also a publicly accessible set of implementations of the specification that allow businesses to register information about the web services they offer so that other businesses can find them."
Figure 8-4 illustrates how UDDI fits into the overall framework of web services. First, a web service provider publishes information about its service using the appropriate API (the API usually depends on the toolkit used). Then, web services consumers can look up this particular service in the UDDI directory, which will point the consumer towards the appropriate WSDL document(s) housed within the web service provider. WSDL specifies how to connect to and use the web service, which finally unites the consumer with the specific functionality he or she was seeking. Although not required, all of the interactions in Figure 8-4 can occur over SOAP (and probably will in most implementations).
Figure 8-4: The "publish, find, bind" interaction among UDDI, WSDL, and web services. All arrows represent SOAP communications
UDDI directories fall into two categories, public and private. A public UDDI is the most common and is what most companies will use in order to offer their web services to the public. Examples of public UDDI directories are uddi.microsoft.com or uddi.ibm.com. There are also lesser-known public UDDI directories such as xmethods.net.
Private UDDI directories are usually implemented in large corporations for internal or B2B use. These directories are hosted internally at the company and are usually only accessible to the employees or partners of the organization. Since UDDI directories are where many companies offer their web services, it's very useful to query as many directories as possible to see if the company you are assessing has any open services. There are many UDDI clients that can be used in order to search a directory. We commonly use one located on SoapClient.com. Figure 8-5 shows a UDDI search for amazon.
Figure 8-5: A SOAP client performing a UDDI search
The raw UDDI query looks like the following:
POST /inquire HTTP/1.0 Content-Type: text/xml; charset=utf-8 SOAPAction: "" Host: www.xmethods.net Content-Length: 425 <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http:/ /schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/ XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/ XMLSchema"><soap:Body><find_business generic="2.0" xmlns="urn:uddi org:api_v2"><findQualifiers><findQualifier>orAllKeys</findQualifier></ findQualifiers><name xml:lang="en">amazon</name></find_business></ soap:Body></soap:Envelope>
Think long and hard before actually publishing any of your web services to a UDDI. Even though there might be proper authentication in place, it opens up your attack surface. If your company has partners that need a directory of your web services, create a private UDDI with authentication. This way it's not published to the world.
| Note | You should never practice security through obscurity, but it never hurts to practice security AND obscurity. |
Since public UDDI directories are, well, public, it's not hard to find them, and they usually contain fairly innocuous information. Private UDDI directories are a different matter.
If an attacker discovers a private UDDI, then they've usually hit a gold mine, for two reasons. One, most private UDDI directories offer up very interesting web services that comprise the core of the organization's application infrastructure. Two, since most internal, private UDDIs are assumed to be "protected" from outside access, they implement very few security controls, oftentimes not even basic authentication.
If "publish" access is available, where the public has the ability to create or edit the web services in the directory, a common attack might be to rename an existing web service and create an exact copy of that web service as a middle man and record all the traffic or even manipulate the traffic on the fly.
Discovering UDDI in most cases is quite simple. Many companies will have a uddi.site.com and accessing their methods is as simple as sending a query to http://uddi.site.com/inquiry, or for publishing access http://uddi.site.com/publish. Some other common locations are shown in Table 8-1.
| /uddi-server/publish | /juddi/publish |
| /uddi-server/inquiry | /juddi/inquiry |
| /uddi/inquire | /wasp/uddi/inquiry/ |
| /uddi/publish |
DISCO
Discovery of Web Services (DISCO) is a Microsoft proprietary technology available within their .NET Server operating system and other .NET-related products. To publish a deployed web service using DISCO, you simply need to create a .disco file and place it in the web service's virtual root directory (vroot) along with the other service- related files (such as .asmx, .wsdl, .xsd, and other file types). The .disco document is an XML document that contains links to other resources that describe the web service, much like a WSDL file containing the interface contract. The following example shows a simple DISCO file:
<disco:discovery xmlns:disco="http://schemas.xmlsoap.org/disco/" xmlns:scl="http://schemas.xmlsoap.org/disco/scl/"> <!-- reference to other DISCO document --> <disco:discoveryRef ref="related-services/default.disco"/> <!-- reference to WSDL and documentation --> <scl:contractRef ref="stocks.asmx?wsdl" docRef="stocks.asmx"/> </disco:discovery>
The main element of a DISCO file is contractRef, which has two attributes, ref and docRef, that point to the WSDL and documentation files for a given web service. Furthermore, the discoveryRef element can link the given DISCO document to other DISCO documents, creating a web of related DISCO documents spanning multiple machines and even multiple organizations. Thus, .disco files often provide an interesting treasure trove of information for malicious hackers.
In its .NET Framework SDK, Microsoft published a tool called disco.exe that connects to a given DISCO file, extracts information about the web services discovered at the specified URL (writing output to a file called results.discomap), and downloads all the .disco and .wsdl documents that were discovered . It can also browse an entire site for DISCO files and save them to the specified output directory using the following syntax.
C:\> disco /out:C:\output http://www.victim.com/service.asmx Microsoft (R) Web Services Discovery Utility [Microsoft (R) .NET Framework, Version 1.0.3705.0] Copyright (C) Microsoft Corporation 1998-2001. All rights reserved. Disco found documents at the following URLs: http://www.victim.com/service.asmx?wsdl http://www.victim.com/service.asmx?disco The following files hold the content found at the corresponding URLs: C:\output\service.wsdl <- http://www.victim.com/service.asmx?wsdl C:\output\service.disco <- http://www.victim.com/service.asmx?disco The file C:\output\results.discomap holds links to each of these files.
In most situations prospective clients won't know the exact address of the .disco file, so DISCO also makes it possible to provide hints in the vroot's default page. If the vroot's default page is an HTML document, the LINK tag can be used to redirect the client to the .disco file:
<HTML> <HEAD> <link type='text/xml' rel='alternate' href='math.disco'/> </HEAD> ... </HTML>
If the vroot's default page is an XML document, you can use the xml-stylesheet processing instruction to accomplish the same thing:
<?xml-stylesheet type="text/xml" alternate="yes" href="math.disco"?> ...
Although DISCO is probably going to be supplanted by the more widely accepted UDDI specification, no doubt many developers will implement DISCO for its less complex, lighter-weight approach to publishing web services. Combined with its ready availability in Microsoft's widely deployed technologies, DISCO or something like it will probably prove a good target for malicious hackers seeking information about web services.
Similarities To Web Application Security
Web services are in many ways like a discrete web application. They are comprised of scripts, executables, and configuration files that are housed in a virtual directory on a web server. Thus, as you might expect, many of the vulnerabilities we've discussed throughout this book also apply to web services. So, don't selectively ignore the basics of web application security just because you've deployed this new thing called a "web service." See Appendix A for a checklist of web application security basics.
| | ||
EAN: 2147483647
Pages: 127