SOAP/XML Firewalls

Web services are already a reality for many organizations and are just around the corner for most of the rest of us. Web services rely heavily on Simple Object Access Protocol (SOAP) and XML technologies to tie heterogeneous business systems together. (For an overview of Web services, see the sidebar "The Promise of Web Services," page 36.) However, SOAP and XML expose a new attack surface to your organization that could potentially let intruders penetrate to the core of your crucial business systems. Packet-level firewalls can't help you secure Web services traffic because they can't detect SOAP and XML traffic. For example, because SOAP typically uses HTTP or SMTP, it easily passes through traditional firewalls—a phenomenon known as the port 80 problem.

So, just when you thought firewalls had matured and you could move on to other security concerns, a new kind of firewall has appeared: the SOAP/XML firewall. Let's explore this new segment of the firewall market and its key players.

XML and SOAP
Before I explain what a SOAP/XML firewall is, let's talk about what XML and SOAP are. Like HTML, XML is a markup language that provides a platform-independent standard for exchanging information between systems on the intranet and Internet. XML differs from HTML, however. HTML is static: It provides a finite set of ways to structure text information. When new needs arise, the HTML standard must be updated to accommodate them. In contrast, XML is a more abstract markup language that provides built-in extensibility through a schema that you define.

XML provides a way to format or structure data and commands or transaction requests. Two applications that support the same XML schema can easily exchange data and request transactions. But although XML lets you assemble a message, it doesn't address getting the message from the client to the server and back again. That task is the job of a protocol—SOAP, in the case of Web services.

SOAP gives applications a way to send XML-based messages over a network within HTTP or SMTP. When one application needs another application's services, the first application formats a service request (i.e., a function name and parameters) into XML, then packages the request in a SOAP envelope and sends it. The target application opens the envelope, executes the request, then uses SOAP to return a response. Environments such as Windows .NET Framework let the application developer work at a high level of abstraction, but the Framework still relies heavily on SOAP and XML, so related security concerns still come into play.

SOAP/XML Risks
Because of XML's platform-independent nature and its ability to let disparate systems interface easily, most Web services use well-known XML schemas and consequently are vulnerable to a much broader variety of potential attacks than are narrower technologies such as Distributed COM (DCOM) and EDI. As a result, you face a greater likelihood of people sniffing the data, nonauthenticated clients directly connecting to and trying to retrieve data from your Web services server, and Denial of Service (DoS) attacks that use malformed messages to exploit a well-known schema. Web services that expose the functionality of core applications (e.g., SAP R/3) and organizations that implement Web services without taking care to secure them expose their soft underbelly to the world. You might even have Web services active in your network and not know it—for example, SAP R/3, which covers everything from purchasing and financials to human resources (HR), natively supports more than 2000 SOAP/XML interfaces.

Traditional firewalls, which look at the world in terms of IP addresses, ports, and protocols, address risks that occur at a much lower level than the level at which SOAP and XML reside. Instead of determining whether to pass a given packet to the internal network, SOAP/XML firewalls validate traffic in terms of Web services, individual messages, and data elements and evaluate whether to let a given requester access a specific operation. XML-embedded malware, such as worms, Trojan horses, and DoS attacks, are risks with SOAP and XML.

   Previous  [1]  2  3  Next