7.1 Web services: The risk assessment

This candid assessment of how Web services are currently being viewed and used by enterprises should not be construed in any way as portending the demise of Web services or as an indictment of the enabling technologies associated with Web services. Much of what has transpired has to do with a climate of uncertainty and fear that came to be independent of Web services. At the time of writing, I am unaware of any security breaches that have been attributed to Web services. This could, however, be attributed to the prudence shown to date when it comes to the use of Web services.

At this juncture it is worth reiterating that when everything is said and done, the basic Web-services model, which is based entirely on the exchange of XML documents, does protect users from viruses and worm-like security threats. Even the potential danger from the optional SOAP attachment capability can be negated by ensuring that the application invoking Web services does not automatically open any attachments without explicit authorization from a designated systems operator. This type of control, which can be enforced via the calling application, should not be underestimated or ignored. The calling application, which would typically be written in-house or developed specifically for an enterprise, does have total control over all of the interactions that take place with invoked Web services.

When a Web service sends information back to the application, in the form of one or more documents conveyed using SOAP, it is still up to the application as to how it processes those documents. Enterprises could insist that developers design applications like the Java applet sandbox model ” that is, information sent back from a Web service cannot in any way cause the application to perform any malicious or unexpected actions. In other words, the application developers have to do their utmost to prevent scenarios similar to the unpredictable but inevitably dangerous results in the event of buffer overflow security exposures that are currently plaguing Microsoft s Windows software. One of the key things to remember in this context is that the calling application can play a pivotal role in ensuring that Web services can t compromise enterprise resources.

In practice, the real dangers with Web services relate to bait-and-switch or Trojan horse scenarios that set out to deceive the calling application. This is where a Web service is not what it claims to be ”particularly when it is dealing with sensitive information (e.g., credit card details, medical records, financial data). For example, the Web service, in addition to performing what it is supposed to do and thus satisfying the requirements of the calling application, may also be performing nefarious actions with the information it receives ”unbeknownst to the users of that application. A Web service being provided at a remote site, by an unknown third party, unfortunately , has plenty of scope and opportunity to engage in such unauthorized and unethical behavior. For example, an unscrupulous Web-service provider is likely to be able to intercept incoming or outgoing data at multiple points within the processing stack and make unauthorized copies of the data.

There are multiple scenarios that pertain to such rogue Web services. The key scenarios that one needs to be on the guard against include:

A Web service that is corrupt from inception despite masquerading as being above board and respectable ”that is, one that has been developed from scratch to scam unsuspecting users. This can be thought of as a Trojan horse setup.
A legitimate , bona fide Web service that gets swapped out, with or without the knowledge and concurrence of its provider, by a rogue Web service that emulates all the functions of the original but in addition performs illegitimate operations behind the scenes. This is a bait-and-switch scenario. A variation of this would be for the calls to the genuine Web service to be intercepted and diverted to a rogue Web service.
The platform on which a bona fide Web service is being run on is compromised, unbeknownst to the service provider, and thus enables a hacker to intercept or alter the data that is being processed by the Web service. This is the concern people currently have with Windows platforms, given the various documented security vulnerabilities that could enable a hacker to surreptitiously take control of a Windows machine. This is a platform vulnerability “ related issue, which, at present, is focused mainly on Windows platforms ”though other platforms could also, in theory, be compromised by a relentless hacker.
A bona fide Web service offered by a respected provider that has, nonetheless, been compromised, covertly, by one or more members of the development team. This is another variation of a Trojan horse scenario.
A rogue or compromised Web service could flood the calling application with spurious or continually duplicated data, thus creating a denial-of-service (or replay attack in the case when duplicated data is being used) scenario at the application end.

Note that having service contracts or service-level contracts per se will not safeguard an enterprise from such rogue or compromised Web services that intend to deceive the calling application. There are tools being developed that will enable a Web-service evaluator to determine the various actions that will be performed by a Web service, depending on the types of XML input parameters it receives. These types of tools will supplement and simplify the source-level review of Web services to determine their integrity.

WebInspect 3.0 from SPI Dynamics (www.spidynamics.org) is one such tool. It sets out to assist in assessing the fidelity of a Web service by exploring all of the XML input parameters it claims to accept and then performing various parameter manipulation on each XML field, looking for vulnerabilities within the service itself. There are multiple advantages to using these types of automated execution path mapping tools. If well conceived, as WebInspect 3.0 indeed appears to be, such tools can be thorough and systematic ”thus ensuring that all potential paths have been adequately explored. They could also bypass the need for source-code-level review ” especially if, for intellectual property reasons (if nothing else), the Web-service owner is unwilling to share source code with any potential evaluator, particularly if there is no financial commitment already in place.

But here, however, is the rub. Even a line-by-line source-code review of a Web service is not a safeguard against rogue or compromised Web services. That is the problem. There could be a bait-and-switch or data interception outside the Web service. Moreover, the platform could be infiltrated at a later date. The bottom line is that safeguarding against rogue Web services is a convoluted challenge that has to be carefully pursued, in the case of remotely-invoked Web services, on a case-by-case basis.

In addition to these dangerous rogue Web-services scenarios, there is also the ever-present concern that information exchanged with a remote Web service, over the Web, can be intercepted or diverted during transmission. Encryption such as 128-bit SSL, obviously is the first-cut protection against such unauthorized access, though one can always argue, quite cogently, that given enough time and processing power this type of encrypted data can be eventually deciphered. However, the real key here is obviating any meaningful ROI of trying to intercept and deencrypt the data in question. The bottom line here has to do with making realistic determinations as to the types of data that are to be transmitted. If the data are extremely sensitive or valuable , then maybe they should not be sent across the Web. Figure 7.2 takes the standard remote Web-services model introduced in Figure 1.2 and annotates it to show how and where this model may be compromised.

Figure 7.2: Areas where security in a Web-service configuration may be compromised.

7.1.1 Growth scenarios for external Web services

All of this said, one can come up with the following examples of how and when enterprises may still be able to safely and gainfully use the originally postulated remote Web-services model in the context of new applications:

If the remote Web service is being used to process relatively innocuous data ”for example, sending a zip code to receive mapping, weather, or traffic data; sending a flight number to ascertain the estimated time of arrival for that flight; sending unqualified numeric strings for currency conversion or sales tax computation.
Web service has been thoroughly vetted, at the source-code level, and is being hosted by a trusted provider that offers audited , collaborative change control (i.e., Web service cannot be updated without documented permission) as well as continuous remote monitoring to ensure that no changes have been made to the Web-service software or infrastructure.
Web service dealing with scientific data (e.g., material strength coefficients, chemical properties, etc.) offered by academic or nonprofit organizations.
Web services that deal with potentially sensitive but nonetheless overtly public-domain information (e.g., property tax records from local authorities, voter registration records, court rulings, etc.).
Required Web service, possibly dealing with sensitive information, is only available on a remote invocation basis from a specific organization, albeit with elaborate access control, authentication, and encryption mechanisms in place (e.g., a tax-related service from a federal or state tax authority, employment eligibility “related data from an immigration authority, homeland security “related updates from the pertinent authority).

There can be exceptions to this list. For example, management of a company in a highly cut-throat, competitive market sector (e.g., car rental, hotel reservation, stock brokerage) may argue persuasively that even apparently innocuous data related to its business operation could be used by the competition to gain a market edge. In such situations even zip codes, flight numbers , or unadorned numerical strings can be construed as constituting vital corporate data that has to be carefully safeguarded.

To be fair, in today s highly competitive global market, with the data mining tools that are readily available, information such as zip codes, flight numbers, currency conversions, and sales tax calculations could be dissected, analyzed , and reanalyzed to determine what or how a company is doing. Even the number of calls to a specific Web service (e.g., shipping rate calculation, sales tax calculation) over a given period of time could be used to determine the health and vitality of a company. Therefore, depending on the specifics, there can always be valid reasons as to why an enterprise may determine that using an external Web service is just not the prudent thing to do ”despite all assurances of Web-service integrity, end-to-end encryption, and the innocuousness of the data.

At this juncture it should also be noted that enterprise-level applications, though a key and potentially highly lucrative market, are by no means the only market for Web services. There is still a huge market for Web services in the nonenterprise application arena. One could even argue that from a Web-services perspective, this personal-use market, with some overlap with the small office, home office (SOHO) market, could be as large and important as the enterprise market.

Remind yourself of all the ingenious, incisive, and magnanimous freeware and shareware software that is readily available on the Web and outside of it. The creators of all such software, as well as their successors, are prime candidates to create a whole new genre of freeware and shareware software based on the original, mix-and-match, plug-and-play Web-services paradigm. This market, which is not as susceptible to or concerned about information pilferage, is ideally suited to truly exploit the platform-independent, dynamic invocation promise of XML Web services. The bottom line here is that the scope and applicability of Web services are not restricted purely to the enterprise market. Even if enterprises persevere in using Web services predominantly on an intranet/extranet basis, remotely invoked Web services, running on third-party platforms, can still flourish within the nonenterprise sector.

Noncorporate portals (e.g., public portals or specialized content portals), are another growth area for externally invoked Web services. As mentioned in Section 1.2, Web services complement portals. This was why IBM felt compelled to institute the concept of Web Services for Remote Portals (WSRP) ”where the term remote in this instance alludes to remotely invoked Web services, in this instance, Web services with integrated GUIs. Remotely invoked Web services from diverse third parties are the ideal, cost-effective way for a portal provider to offer customized, value-added functionality.

To begin with, most portals will want to use Web services for much of the de rigueur but nonproprietary utility functions users expect from a public portal: weather, sunrise /sunset times, phases of the moon, top news stories, horoscopes, and so on. Web services also provide portal providers with an enormously powerful, flexible, and standards-based mechanism for integrating external functionality. Consequently, it is safe to say that remotely invoked Web services will certainly flourish within the continually expanding portal market.

Another nascent but potentially burgeoning market for Web services is the voice and smart phone arena. There is already considerable momentum around VoiceXML (i.e., Voice eXtensible Markup Language) fostered through the VoiceXML Forum (voicexml.org) an industry organization founded by industry titans AT&T, IBM, Lucent, and Motorola. VoiceXML is a standard essential to making Internet content and information accessible via voice and phone. Given that it is a bona fide XML derivative, it can be easily adapted for use with existing Web-services technology. In addition to voice-based applications, there is an insatiable demand for value-added functionality for the increasingly powerful and versatile cell phones ”some of which already support Java virtual machines. Web services are well poised to help developers exploit this new and exciting market for sophisticated software, interactive voice applications, and smart phones.

The final point that should be noted is that the software vendor community, with IBM in the lead, recognizes that there is a huge pent-up market for security and management tools that would make remotely invoked Web services more palatable for enterprise use. IBM s Web-service gateway, which was introduced in the spring of 2002, along with SPI Dynamics WebInspect 3.0 and other software vulnerability assessing software such as Sanctum s AppScan (www.sanctuminc.com), are precursors of things to come.

The express goal of IBM s proxy capability for Web services is to enable the externalization of Web services beyond the boundaries of an enterprise network. This gateway, which serves as a wonderful prototype for subsequent offerings, can act as a bidirectional proxy for services outside an enterprise firewall as well as for those within. It is, in effect, an XML application firewall for Web services; it ensures, per the now-accepted firewall model, that there are no unguarded end-to-end connections into an enterprise network that can be exploited by hackers. This gateway does not safeguard users from rogue or compromised Web services. However, if you do plan to use an adequately vetted and thus trusted external Web service, doing so through this gateway will ensure that all the Web services “related interactions are controlled, deterministic, and protected (as far as possible) against abuse by hackers.

When an enterprise application wishes to use external Web services, this gateway, using the WSDL definitions for the required service, will import its functionality into the gateway ”albeit in the form of an outbound remote call to the original Web service. However, the calls from the enterprise application to the Web service now get terminated at the gateway. There is no end-to-end connection between the calling application and the original Web service. Instead, calls to that external Web service are intercepted and serviced by the gateway, as shown in Figure 7.3.

Figure 7.3: Using a Web-services gateway to act as an XML application-level firewall between the calling application inside the corporate firewall and an externally invoked Web service.

The gateway in essence acts as an application-level Web-service firewall. It performs a corollary function when applications outside the enterprise firewall wish to invoke a Web service that is deployed inside the firewall.