Anything that accepts input from a caller and then retrieves and returns business-critical data to the caller on the basis of that input should set off mental alarm bells. And that goes double for Web services, which need to be approached as warily as you would any dangerous beast.
Generally speaking, eWeek Labs advises that early adopters take it slow with Web services rollouts, particularly with externally accessible Web services—the security infrastructure just isnt there yet.
One of the core problems is the near-total lack of attention paid to security issues when the SOAP (Simple Object Access Protocol) 1.1 Web services specification standard was developed.
Section 8 of the SOAP 1.1 World Wide Web Consortium Note, “Security Considerations,” (available at www. w3.org/TR/SOAP) states, “Not described in this document are methods for integrity and privacy protection. Such issues will be addressed more fully in a future version(s) of this document.”
The next version of SOAP, Version 1.2, is in development but has the same blind spots.
This sin of omission is the reason there is no consistency in how currently available Web services libraries implement security. Frighteningly, most libraries do not provide any security features, since none were required by the SOAP specification.
Making It Work
Security does need to be kept in perspective. When a business need exists, its the IT departments job to create or find the technology to satisfy that need, including applying security that will protect the organization and its partners. And there will certainly be a compelling business need for Web services at many organizations: They provide a unique combination of interoperability, accessibility and simplicity, and they will be at the center of future business-to-business networks.
Even with the current immaturity of the standards, Web services can be deployed securely—with enough effort. However, we warn that, for the rest of the year at least, organizations will probably need to do more custom coding than they would like.
The only close-to-straightforward way to deploy Web services security right now is to wrap services in a secure transport protocol.
HTTPS, the encrypted version of HTTP, coupled with built-in Web server authentication techniques such as digest authentication, will be the most common option for the foreseeable future.
However, inherent incompatibilities between the simple HTTP protocol and the sophisticated needs of business messaging make HTTP (and HTTPS) a poor fit for the security needs of Web services. HTTP is the most common approach simply because it is so universally supported.
For internal use, HTTPS is a fine choice. However, for external use, especially for more critical services, we recommend instead using a message queue system such as IBMs MQSeries or Microsoft Corp.s Windows Message Queuing (a feature of Windows 2000 Server). These systems provide sophisticated delivery guarantees even across public Internet links, combined with built-in user authentication, encryption, message nonrepudiation and auditing features—in short, all the security features that SOAP lacks.
As a second-best option for external connections, wed advise that sensitive Web services be offered only over IP Security- based VPN (virtual private network) links between the host organization and business partners. Combined with Web server user-level authentication, this approach provides network traffic isolation along with strong authentication and encryption. (SOAP data is passed as easy-to-capture text strings, so transport protocol encryption is particularly important.)
A New Kind of Beast
Web services published using a Web server are implemented through scripts or compiled programs that run when a matching HTTP request arrives, so its fairly straightforward to use the file access control tools provided by all the major Web servers to require some form of user authentication before the Web services program can be accessed.
However, a dependency on HTTP also means that SOAP inherits HTTPs key security weaknesses: its statelessness and lack of delivery guarantees.
HTTP provides no information about an ongoing conversation between a client and a server, which makes it considerably more difficult to build Web services that require two separate messages from a business partner rather than just one.
For example, if Web server user authentication is not used, user authentication data such as user name and password will need to be included by the caller with every SOAP request.
State of Standards
There is important standards development work going on to define a full security framework around XML-based Web services, but this work is still in its early stages and will not be incorporated into Web services products for several months.
The key efforts to watch are the W3Cs XML-Signature Syntax and Processing standard (which became a W3C recommendation Feb. 12), providing a way to sign, check the integrity of and verify sender identity of XML-based messages; the W3Cs XML Encryption Syntax and Processing standard (currently a W3C working draft), providing a way to encrypt XML data; and the W3Cs XML Key Management Specification (currently a W3C working draft), providing an XML-based interface to a public-key infrastructure.
Even with a stronger framework, security will eventually be compromised. Damage limitation will depend on how defensively the system was configured.
As with any code exposed to outside users, defensive coding practices are a must for Web services code: Perform existence, range and logical checks on all passed parameters before using them; run the Web server or script engine executing the code using a restricted operating system account; and use database log-ins that are limited to just the subset of data the Web service needs using database access control permissions.
West Coast Technical Director Timothy Dyck can be reached at timothy_dyck@ ziffdavis.com.
Also in this Special Report
- Ignorance: The Hackers Best Friend
- Security Roundtable
- Threats to Come
- Trail of Destruction: The History of the Virus
- Community Builds Security: Labs Answers Your Security Questions
- WLAN Hardening Checklist
- Application Hardening Checklist
- Operating System Hardening Tips
