Information Security Technical Report (2005) 10, 228e235

Web services: Developers dream or hackersheaven?

Mark Curphey

Abstract This article provides a high level of web services security, the evolvingstandards and discusses security issues that these standards do not address. Specif-ically it discusses:

� What is a web service and why are they so significant� The current state of web services security� Web services security standards� A hacker’s view of web services

ª 2005 Elsevier Ltd. All rights reserved.

Introduction

Technology trends come and go and no matter howenormous the potential ramifications of a particularnew technology ‘‘could’’ be, many wise industrypundits sit at the sidelines and watch the tide washup and then wash away again. Web services arecertainly not falling short in their level of industryhype and expectation, but beneath the sometimesfrivolous words of the trendy spectators and spec-ulators, web services may be the equinox tide; thattide which rises higher, stays longer and whoseresulting effects are different from the daily drone.Web services are based on principles of simplicity,commonality, extensibility and interoperability andare loosely coupled language neutral and platformindependent. It is these very fundamental princi-ples that may just give them the meaning to effecta sustainable change in the way we plumb data

E-mail address: mark@curphey.com

1363-4127/$ - see front matter ª 2005 Elsevier Ltd. All rights resedoi:10.1016/j.istr.2005.09.004

communications between software in the everincreasing connected world we live in.

The article will explore:

� What is a web service and why are they sosignificant

� The current state of web services security� Web services security standards� A hacker’s view of web services

What is a web service and why are theyso significant?

To define what a web service is we need to firstunderstand that the term itself is generic andwithout formal definition. One common definitionis that a web service is an application thatcommunicates using standardized web technology.Communication is usually with another applicationi.e. machine to machine.

rved.

Web services: Developers dream or backers 229

If you think of a typical web site or webapplication it is designed for human users. A userinteracts with a web browser; the client applica-tion. This application makes requests for informa-tion to a web server using the hypertext transferprotocol (HTTP) which forwards the request (typ-ically a combination of a web address or URI anda set of attributes or parameters) to an applicationfor processing. The application will process therequest build a reply usually in the form of a pagewhich it sends as some markup to the browser thatwill in turn render it to the user.

A web services client, a software applicationrunning in a machine (and usually hand coded aspart of a larger system) can discover services thatare available to interact with by connecting toa Universal Description, Discovery and Integrationregistry. When a service of interest is discoveredways of interacting with the services can be pro-grammatically determined by interpreting an XMLdocument written using the Web Services Descrip-tion Language (WSDL). This WSDL will describe theinterface from which to communicate. A client canthen construct a request based on this informationand hold a meaningful conversation and performtransactions. The conversation usually uses theSimple Object Access Protocol (SOAP) which isessentially XML over HTTP. Put another way com-munication usually takes place using a very simplestateless protocol and payloads are carried usinga meta language. Services technology is emergingrapidly and while UDDI technology provides theplumbing for self-serving web service communica-tion, many more simple services implementationssimply allow a client to communicate with anapplication using a predefined set of interfaces.

With this ‘‘lowest common denominator’’ ap-proach to software communication, life becomessignificantly easier to tie technology together andwith the notion that disparate systems can not onlycommunicate with each other but also program-matically decide whom to communicate with andhow to do it; the power of web services becomesevident. The dream of a computer being able toperform useful tasks such as automatically go outonto the Internet and querying a central registry ofcar dealers for those who have Ferraris; thensystematically going to each garage and askingwho has a 360s in red with less than 10,000 mileson the clock is a reality. Companies today arebuilding web services that aggregate financialservices accounts across disparate business unitsto provide cross-sell and up sell opportunities;expose vast inventories of stock in order for peopleto build specialized and customized front ends(a great example of this is Amazon.com) and

integrate data from legacy systems like main-frames into modern architectures and systems.

In the space of the last year web services haveseenanother significant right hand turnwith the fastadoption of AJAX. AJAX standards for AsynchronousJavaScript and XML and is a way to provide a richclient experience to end users while using standardweb technologies. A great example of AJAX tech-nology in use is Google Maps (http://maps.google.com) where through a regular web browser youhave an interactive experience where the user in-terface changes without the needs to ‘‘click’’ but-tons, much like persistent client applications.

While the basic staples of services discovery,description and communication (UDDI, WSDL andXML/SOAP) are relatively well understood, thevalue add technology that provides richer experi-ences to the data description and data transportare evolving at a fast pace (Figs. 1e3). Many spe-cialist XML schemas have been standardized rang-ing from ways to describe and exchange legaldata (LegalXML) through to ways to exchangeemergency management information (EDXML).While some standards define security attributes in-side their own schema, the nature of the XML’s ex-tensibility means that most of the standards deferto additional mechanisms and standards to provideappropriate levels of security.

The current state of web servicessecurity

As the technology has evolved, not one definitivestandards body has asserted de-facto or de-jourauthority and as a result pieces of the web services(security) puzzle are controlled in various placeson the Internet. However, two bodies are emergingas the predominant creators of standards in thespace, the W3C and OASIS.

In their own words the World Wide Web Consor-tium (W3C e http://www.w3c.org) develops inter-operable technologies (specifications, guidelines,software, and tools) to lead the web to its fullpotential and was created in 1994. The W3C hasdeveloped key data specifications including thestandard for XML itself.W3C standards tend to focuson specifications for describing and processing thedata itself including XML, XPATH, XSLT and set ofXML crypto related standards such as XML Encryp-tion and XML Key Management.

In their own words, OASIS (Organization for theAdvancement of Structured Information Stand-ards) is a not-for-profit, international consortiumthat drives the development, convergence, andadoption of e-business standards. OASIS is the

230 M. Curphey

Figure 1 A typical web services client discovering a web service using UDDI and then requesting service using SOAP.

home of some impressive security standards suchas SAML (Security Assertion Markup Language) andXACML (eXtensible Access Control Markup Lan-guage) discussed later. The most important secu-rity standard from OASIS is the widely adopted andimplemented WS-Security (web services security).In practical terms of course OASIS is driven byvendors with a vested interest in specific standardsand has its fair share of criticism about politics andprocess from those who have participated insome standards creation. Lately vendors such asMicrosoft and IBM appear to have been creatingstandards outside of the OASIS process and thendonating them to the standards body. What is notin question is that much investment has been made

in web services security standards and while theyallow developers to build rich security functional-ity into simple and complex applications alike,implementations of the relevant standards alonefar from guarantees security as we will discuss insection A hacker’s view of web services.

Web services security standards

With the vast array of standards published or underdevelopment and rich implementation librariesbeing developed by the likes of Microsoft, navi-gating the standards and implementing the ‘‘forpurpose’’ specification is perceived by many de-velopers as half of the battle.

Figure 2 Request when using transport layer security.

Web services: Developers dream or backers 231

Figure 3 Request when using message level security.

In general you can partition the standards intotwo course categories:

� Standards that directly apply security servicesto data or transport of other services

� Standards that describe and exchange securitycontext

Standards that directly apply securityservices to data or transport of otherservices

XML EncryptionXML Encryption provides a mechanism to protectparts of an XML document, usually an individualelement or sets of elements. In complex systemsand systems where documents can become signif-icantly large the overhead of providing encryptionto the entire document is neither feasible norpractical. Additionally in today’s systems of inter-connectivity and dynamic routing transport secu-rity which usually provides point to point securityrarely provides a flexible enough mechanism toguarantee protection across the entire transporta-tion path.

XML Encryption supports encryption of any arbi-trary digital data format including XML documentsthemselves. The encrypted data are represented orreferenced by XML format and include ways torepresent keys, algorithms and other attributes.

<EncryptedData ID¼" " Type¼"anyURI">(<EncryptionMethod Algorithm¼"anyURI"/>)(<ds:KeyInfo/>)<CipherData>

(<CipherValue> j<CipherReference>)<CipherData/>(<EncryptionProperties/>)

<EncryptedData/>

Any example of encrypting the Social SecurityNumber of a customer record using XML Encryptionis as follows:

<Customer name¼"Mark Curphey" id¼007><Address>Boston, USA<Address/><SocialSecurityNumber>

<EncryptedData xmlns¼http://w3c.org/2001/04/xmlenc# Type¼"http://w3c.org/2001/04/xmlenc#Content">

<EncryptionMethod Algorithm¼"http://w3c.org/2001/04/xmlenc#tripledes-cbc"/><CipherData>

<CipherValue>45a64f45¼e4<CipherValue/>

<EncryptedData/><SocialSecurityNumber/>

<Customer/>

XML SignatureAs with the XML Encryption standard, the XMLSignature standard is designed to provide a mecha-nism to digitally sign any arbitrary digital content. Inpractice it is usually used to sign portions (usuallyindividual elements) of an XML document. Addition-ally it is designed to provide a mechanism formultiple signatures. In XML Signature the actualtarget of signature (the data object) is digested andplaced in an element. That element is then itselfdigested and signed. This is called ‘‘indirection’’.

<Signature ID?><SignedInfo>

<CanonicalizationMethod/><SignatureMethod/>(Reference URI?>

<Transforms/>)?<DigestMethod/><DigestValue/>

</Reference>)</SignedInfo)<SignatureValue/>

(KeyInfo/>)?(Object ID?/>)

</Signature>

There are four different ways of relating thedata objects to the signatures and the choices

232 M. Curphey

have some subtle but significant security implica-tions. The first method is where the data objectitself is embedded inside the XML in a techniquecalled ‘‘enveloping’’. The second method is wherethe data object embeds the XML Signature ina technique called ‘‘enveloped’’. The third andfourth ways are both referred to as ‘‘detachedsignatures’’. This is where the data object residesinside the XML document but not inside the XMLSignature element or external to the document.Due to the nature of the signature process wherethe data object is digested and signed care mustbe taken when deciding on how to relate data. IDcollisions are possible when a signature generatedin one context is subsequently dropped in another.

Other relevant standards in XKMS that specifiesa protocol for registering, processing and distribut-ing public keys for use in XML Encryption and XMLSignature and can expose its services using WSDL.

WS-SecurityWS-Security was proposed by Microsoft, IBM andVerisign and can really be viewed as a collection ofrelated individual specifications to provide securitymechanisms to SOAP. The WS-Security profile hasevolved significantly since it was first presented andnow includes specifications to perform very specifictasks and build rich security scenarios.

WS-Security provides message integrity andconfidentiality, by associating security tokenswith messages. Message integrity is provided byXML Digital Signature in conjunction with securitytokens. Message confidentiality is provided by XMLEncryption in conjunction with security tokens.

WS-Policy allows senders and receivers to spec-ify their requirements and capabilities includingattributes for privacy, encoding formats, securitytoken requirements and supported algorithms.

WS-Trust allows unrelated entities to createtrust relationships directly or broker trust rela-tionships through a common trusted third party.The third party may serve to ‘‘translate’’ tokenswhich assert authentication/authorization deci-

WS-SecureConversation WS-Federation WS-Authorization

WS-PrivacyWS-TrustWS-Policy

WS-Security

SOAP Foundation

sions between different formats (Kerberos, SAML,XACML, X509, etc.).

WS-Privacy allows systems to share privacypolicy information and makes decisions aboutsharing of sensitive information based on a formalprivacy policy. It is used in combination with WS-Trust to determine policies for sharinginformation.

WS-Secure Conversation allows a multi-steptransaction to occur without having to establishsecurity for each step of the transaction. Thesecurity mechanisms to protect confidentialityand integrity are established at the beginning ofthe conversation and used throughout the lifetimeof the conversation.

WS-Federation allows systems with commonentities (e.g. customers) to share identity, authen-tication and authorization information about thosecommon entities.WS-Federation perhaps offers thegreatest economic potential for companies duringacquisition and merger frenzy of the Internet age.

WS-Authorization describes the authorization ofweb services based on the identities establishedthrough WS-Trust.

Standards that describe and exchangesecurity context

While the brief overview of the standards abovefocus on providing security for other data, someXML standards have been developed that describesecurity data itself. The two most important andwidely adopted are the Security Assertion MarkupLanguage or SAML and the eXtensible AccessControl Markup Language or XACML.

SAMLSAML is an XML standard for exchanging authenti-cation and authorization credentials over the Inter-net. As such it makes a candidate for integratingdisparate systems by providing ‘‘single-sign on’’.SAML requires an authentication authority whichcan implement any type of authentication service(LDAP, RSA SecurID, username and password ina database, etc.) as long as it is able to speakSAML. An attribute authority asserts attributesabout a user. The policy decision point reviewsthe policies and the authentication/attribute as-sertions to determine authorization. The authori-zation assertion is passed to the policy enforcementpoint.

A simple SAML assertion example is as follows:

<?xml version¼"1.0" encoding¼"UTF-8"?><saml:Assertion xmlns:saml¼"urn:oasis:names:tc:SAML:1.0:assertion"

Web services: Developers dream or backers 233

MajorVersion¼"1" MinorVersion¼"0" AssertionID¼"186CB370-5C81-4716-8F65-F0B4FC4B4A0B" Issuer¼"www.exam-ple.com" IssueInstant¼"2001-05-31T13:20:00-05:00">

<saml:Conditions NotBefore¼"2001-05-31T13:20:00-05:00"NotAfter¼"2001-05-31T13:25:00-05:00"/><saml:AuthenticationStatement AuthenticationMethod¼"password"AuthenticationInstant¼"2001-05-31T13:21:00-05:00">

<saml:Subject><saml:NameIdentifier>

<SecurityDomain>www.example.com

</SecurityDomain><Name>

"cn¼Joe,co¼example,ou¼dev"</Name>

</saml:NameIdentifier></saml:Subject>

</saml:AuthenticationStatement></saml:Assertion>

In a typical usage scenario between some travelrelated sites, SAML might pass assertions to pro-vide single-sign on between an airline, an airrewards provider and a rental car company.

The user may login to the airlines web site andbuy a ticket. He may then decide to rent a car atthe destination. Using SAML the airline site canassert that the user logged in at a certain time usinga password and that login session is valid througha date and time (AuthN assertion). The site can alsoappend an assertion that the user has gold status(attribute assertion). These assertions can be sentto a policy decision point at the car rental companywhich in turn checks the policy store to validate theauthorization assertions. Using SAML the systemscan provide a seamless experience for the end user,passing security information behind the scenesallowing two companies to treat a user as a seam-less customer of both.

XACMLIf SAML defines how identity and access informa-tion is exchanged, XACML defines how to use theinformation. There are two main parts to XACML;a policy description language and a request/response language to present requests for autho-rization and receive replies.

In theexamplebelowawebclientattempts to reada server resource. The servers policy enforcementpoint or PEP has received the client’s service requestand generated an XACML request. The responsecontains a description of the user group the clientbelongs to (controller) and the URI resource theclient is attempting to access (http://xyz.com/

payroll/print.html) along with the action (‘‘read’’)theclient is attempting toperformupontheresource.

<Request><Subject>

<Attribute AttributeId¼"group"DataType¼"http://www.w3.org/2001/XMLSchema#string" Issuer¼"admin@xyz.com">

<AttributeValue>Controller</AttributeValue></Attribute>

</Subject><Resource>

<Attribute AttributeId¼"urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType¼"http://www.w3.org/2001/XMLSchema#anyURI">

<AttributeValue>http://xyz.com/payroll/print.html</AttributeValue>

</Attribute></Resource><Action>

<Attribute AttributeId¼"urn:oasis:names:tc:xacml:1.0:action:action-id" DataType¼"http://www.w3.org/2001/XMLSchema#string">

<AttributeValue>read</AttributeValue></Attribute>

</Action></Request>

The services of what is referred to as the policydecision point entity are invoked to locate anapplicable policy, evaluate it, and return an accessdecision to the policy enforcement point. In theexample, a policy named ‘‘ControllerPolicy’’ wasdetermined to apply to the Request since theTarget element evaluated truly, based on a Sub-ject, Resource, and Action element matches.

The ‘‘ControllerPolicy’’ has a single Rule whichneeds to be evaluated, ‘‘ReadRule’’. If the Ruleevaluation is successful, it will return a ‘‘Permit’’decision. The first evaluation within the Rule is tocompare another Target element against the Re-quest’s Subject, Resource, and Action (‘‘read’’)which all match. Therefore, the Condition isevaluated. The Condition uses a SubjectAttribute-Designator to retrieve the attribute value forthe ‘‘group’’ attribute contained in the Requestand compares it to the Policy AttributeValue(‘‘Controller’’) which matches. The end resultis a Permit being returned from the Policy evalu-ation and returned to the policy enforcementpoint.

<Policy PolicyId¼"ControllerPolicy"RuleCombiningAlgId¼"urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">

<Target><Subjects><AnySubject/></Subjects><Resources><Resource>

234 M. Curphey

<ResourceMatch MatchId¼"urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">

<AttributeValueDataType¼"<http://www.w3.org/2001/XMLSchema#

anyURI">http://xyz.com/payroll/print.html</AttributeValue><ResourceAttributeDesignatorDataType¼"http://www.w3.org/2001/XMLSchema#anyURI" AttributeId¼"urn:oasis:names:tc:xacml:1.0:resource:resource-id"/>

</ResourceMatch></Resource></Resources><Actions><AnyAction/></Actions>

</Target><Rule RuleId¼"ReadRule" Effect¼"Permit">

<Target><Subjects><AnySubject/></Subjects><Resources><AnyResource/></Resources><Actions><Action><ActionMatch

MatchId¼"urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType¼"http://www.w3.org/2001/XMLSchema#string">read</AttributeValue><ActionAttributeDesignator

DataType¼"http://www.w3.org/2001/XMLSchema#string"AttributeId¼"urn:oasis:names:tc:xacml:1.0:action:action-id"/>

</ActionMatch></Action></Actions></Target><Condition FunctionId¼"urn:oasis:names:tc:xacml:1.0:function:string-equal">

<Apply FunctionId¼"urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

<SubjectAttributeDesignatorDataType¼"http://www.w3.org/2001/XMLSchema#

string" AttributeId¼"group"/></Apply><AttributeValue

DataType¼"http://www.w3.org/2001/XMLSchema#string">Controller</AttributeValue>

</Condition></Rule>

</Policy>

As can be seen from the high level overviewof theweb services specifications described above, richformats have been developed to build complexsystems and flexibly deal with complex securityscenarios. Onemight be forgiven for thinking that bysimply choosing the appropriate security standardsand implementing them correctly that constructinga secure web service is guaranteed. Think again!

A hacker’s view of web services

It is fair to say that hackers are several years behindthe ball when it comes to mass exploitation of

cutting edge software and web services are noexception. With modern operating systems provid-ing cannon fodder from which they continue to findnew vulnerabilities and develop exploits, it has onlybeen the last 18 months in which hacker confer-ences have seen presentations on this attack vector.However, the very nature of web services and thepotential consequences of the attacks may heraldthe next generation of attacked infrastructure.

As we described in the introduction web serv-ices provide technology to automatically discoverservices and describe exactly how to communicatewith them. This makes life very easy for anadversary who wishes to query a global UDDI forthe keyword ‘‘banks’’ and then understand thefunctionality that is available. Looking for servicesto potentially exploit really is as easy as queryingan UDDI for a keyword that may describe a serviceand requesting the WSDL. The performance ofautomated web application penetration testingtools (web scanners) has been extremely poor(typical tools find less than 5% of issues in theaverage web site) partially due to the fact thatthese tools struggled to spider web sites anddiscover the attack vectors. This limitation doesn’texist with services. Another popular trick ofhackers is to use popular search engines and lookfor the keyword ‘‘WSDL’’.

Along with the standardization of the technologyhas come the standardization of potential pay-loads. With traditional web applications a commonattack called SQL (Sequential Query Language)Injection has become the scourge of many a website. High profile cases in the US have resulted inmillions of credit cards being available to anyunauthenticated user via a simple web browser.The attack works by tricking the site into runninga database query of the attackers choice.

If a web site took two parameters from the user,the username and the password the HTTP requestmay look like this:

http://www.fs.com/login.asp?user¼bob&pass¼123(Note in itself passing sensitive information viaGET requests brings several issues and is onlyused for illustrative purpose.).

The web server would pass the request to theapplication who would in turn execute a databasequery to compare the data presented against thedata stored.

SELECT * FROM usertable WHERE username¼‘bob’ ANDpassword¼‘123’

A malicious attacker, however, may add n addi-tional database statement such as

Web services: Developers dream or backers 235

http://www.fs.com/login.asp?user¼bob’þORþ1¼1;- -&pass¼123

If this is passed to the application if it executesthe following database query would be called

SELECT * FROM usertable WHERE username¼‘bob’ OR1¼1;- -’ AND password¼‘123’;

Everything after the double dash would betreated like a comment and as 1 always equals 1;the statement would evaluate to true. The attackerwould be authenticated. This unrealistically simpleexample illustrates the technique but not thecommon challenge in successful exploitation. Inorder to perform the query an attacker typicallyneeds to execute in order to read credit card tablesor transfer money from one account to another,complex statements need to be built. These typi-cally involve using statements that join table, sortand order data and perform complex calculations.Each technology implements the Structured QueryLanguage or SQL in a different way and as a resultone injection payload for a site may or may notwork depending on whether the database is Oracleor Microsoft SQL server or indeed if it is a specificversion of those technologies.

Now the important part: web services, however,have standardized ways to query XML documents ina standard called XPATH. XPATH is for web serviceswhat SQL is to databases. To an attacker thestandardization of XPATH means a standardizationof payloads. Injecting malicious XPATH queries intoa web service becomes more predictable and hassignificantly higher success rates. In recent tests Iran against two of the most popular UDDI registrieson the Internet over 50% were susceptible toXPATH injection.

Other attacks gaining prevalence and attentionattempt to create denial of service conditions bysubmitting requests that cannot be processed.When a web service receives an XML document asa request the service must first parse the documentin order to read the instructions and decide what toprocess. One such way to parse the XML documentis called a Document Object Model where the

parser creates an object in memory to representthe XML document. If an attacker submitted an XMLdocument with hundreds of thousands of elementsembedded in the request the parser may require allof the system resources to complete the actionthus creating a denial of service condition.

Conclusion

Web services are an exciting topic with significantimplications to the software industry and thebusiness landscape it supports. The security stand-ards being developed to support deploymentsprovide a rich set of security techniques fromwhich to build security. However, several funda-mental issues in web services architectures andthe fundamental technology that it uses can alsolead to open doors for hackers. Architects anddevelopers need to understand security require-ments of their systems, the security implications inthe entire technology stack and keep themselvesabreast of the methods of attackers. So are webservices a developers dream or a hacker’s heaven.In their current state of deployment they are mostcertainly both. There are many lessons that shouldhave been learnt from developers of traditionalweb application which seem to have gotten lost onthe gold rush for standards creation and theexcitement of implementation.

Mark Curphey is the Vice President of consulting at Found-stone, a computer security consulting and training companybased in the USA. Foundstone are the authors of the popularHacking Exposed series of books and were acquired by McAfeein October of 2004. He has a Masters Degree in informationsecurity and has held roles at various financial services compa-nies including Director of software security at Charles Schwab,one of the US’s largest financial services companies where hewas responsible for developing strategy, policy, architectureand implementation guidance for software produced by over4000 developers all around the world. He founded the OpenWeb Application Security Project (http://www.owasp.org) in2000. He is currently interested in threat modeling, informationsecurity business process management and security metrics.

Mark can be contacted at mark@curphey.com or mark.curphey@foundstone.com.