It is widely acknowledged that security remains a key limiting factor in the broad adoption of Web services. In fact, I wrote about the challenge of Web services security in a prior ebizQ column. That article discussed trust issues between SOAP message consumers and producers, especially in a multi-point routing scenario. However, little has been written about the need to protect Web services deployments from hacker attacks.

Yet, as Web services integration becomes integral to core business processes, protecting Web services from such attacks will become more and more necessary. In this brief article, I want to highlight a couple of ways your Web services infrastructure may be compromised by hackers and what you can do to protect against these attacks.

XML Content-based Attacks

XML content-based attacks employ the technique of embedding malicious content within the XML document. This approach uses XML as a means of transmitting malicious code to the target host, as shown in Figure 1 below. This is akin to the way viruses and worms can sometimes be transmitted as part of an e-mail attachment.

By embedding malicious code within an XML document, the hacker can compromise the system through a number of common attack methods such as buffer overflows, SQL injections and command tampering.

Denial-of-Service (DoS) Attacks on XML Processors/Parsers

DoS attacks targeting Web services will often focus on exploiting poorly written XML processors or parsers. One attack method exploits a poorly written XML processor by having it handle a legitimate but exceedingly large XML document. In some cases, the XML processor will ultimately exhaust host system resources while attempting to handle the document, leading to a host DoS scenario.

A second attack method commonly known as "coercive parsing" exploits XML's document model support for nesting. The idea is to provide a deeply nested or recursively nested XML document such that the XML parser will fail. In each of these cases, the assumption is that many XML processors or parsers are written without taking into account the need to calibrate an upper limit to processing parameters or resource consumption.

Mitigating the Threat

Armed with a basic awareness of how Web services architectures can be compromised, what can we actually mitigate against these and other threats? Here are three basic steps you can take to immediately protect your Web services deployment:

• Keep Patches Current: Just as with any operating system service, applying the latest patches related to Web services will minimize exposure to known vulnerabilities. An example of how Web services vulnerabilities can potentially have a pervasive effect is a SOAP vulnerability discovered earlier this year in Oracle 9i application server. Failure to apply the appropriate patch offered by Oracle would leave your Oracle 9i application server vulnerable to a DoS attack.
• Invest in the Right Security Tools: Network security devices are often inadequate for securing Web services. Providing Web services protection coverage requires that firewalls or intrusion prevention systems (IPS) have the following attributes: First, tools must be effective at monitoring port 80 traffic since SOAP over HTTP is still widely implemented. Second, they must be able to perform full application layer inspection including the inspection of payload. These tools must be "XML-aware" or be customized as such through a scripting language. Many "traditional" tools fall short here because they only perform rudimentary application layer inspection or cannot be customized to handle XML documents. Finally, it is preferable for security tools to be managed by a common security console in order to reduce the management overhead. Specialized XML firewalls include products from Vordel and Reactivity. Products from "traditional" vendors worthy of consideration include Netcontinuum, Teros and NFR Security.
• Perform Regular Security Audits: Security auditing should be conducted on a regular basis, preferably by a third-party security consulting company. The security audit should include vulnerability assessment, penetration testing, load testing and if possible, code reviews of in-house custom code. Especially when a Web service integration facilitates cross-enterprise transactions with partners, the additional benefit of being "certified" by an external reviewer will mitigate business and legal concerns regarding the security of the system.