Safeguarding Web services is a lot like protecting your Web-based applications from attack. The current crop of application-layer security solutions can look for malformed Web traffic, URL tampering, and the like, but it does not look deep into SOAP messages or scrub XML for malicious content, thus leaving Web services exposed.
Web services come with their own specific vulnerabilities and security needs. By design, each one has an associated WSDL document that is basically a blueprint for the service. The document details the messaging request and response for the service in XML, what parameters (including data type) the service expects, and what operations are available via the service - a return, a stock quote, or account update, for example. By analysing a service's WSDL document, a hacker knows exactly what the service is supposed to do and which parts are open to attack via techniques such as malformed SOAP messages and other XML parser attacks.
Forum XWall Web Services Firewall from Forum Systems can help you fight back and protect your exposed Web services. By peering into each SOAP message, it allows or denies inbound connection attempts based on policies and rules you define. Also, Forum XWall enforces XML intrusion prevention and validation and provides multiple levels of monitoring and auditing.
Available as an appliance, software you install on your hardware, a plug-in to Microsoft Internet Security and Acceleration (ISA) Server, or embedded on a PCI 500 card, Forum XWall has most of the tools necessary to protect your Web services from attack.
For my test, I installed Forum XWall's software version on a Compaq ML530 running Windows 2003 Server with IIS and UDDI. Installation was straightforward, although initial configuration took some knowledge of XML and WSDL to get things going. In a production setting, Forum XWall should be run on a separate server so that it can efficiently proxy your Web services to consumers and simplify installation.
In order to protect a Web service, you have to create at least one policy. This is done by importing a WSDL document either from a file, URL, or your UDDI directory. After the document is imported, the methods of the Web service are broken out and listed by XWall. You define various intrusion detection rules on inbound messages and can even disable specific methods allowed by the service. This release comes with an upgraded user interface that makes policy creation and maintenance much easier than it was previously.
XML intrusion detection and prevention (IDP) is the core reason for deploying an XML firewall. With Forum XWall, you can validate the SOAP message and the underlying XML by comparing it to the services' WSDL document and then enforcing your policy. Forum XWall also prevents attackers from scanning your WSDL documents.
The power of Forum XWall becomes apparent as you begin to define validation criteria and access control lists for each Web service operation.
For example, on my Google search service, I created an IDP rule that would abort request processing if there were more than 50 total elements in the XML or if the document exceeded 500KB in size. You can create different IDP rules for specific times of day and specify how you want the event logged. Forum XWall allows you to create a global IDP rule set, but you can override or add to these rules for each policy.
XWall will also help protect your Web service against DoS attacks in a couple of ways. It uses a custom XML parser to scan messages and validate them before they hit the Web service's parser. And through the use of IDP rules, XWall can limit the message size or total number of bytes per minute, hour, or day, minimising the chance of an unknown attacker overwhelming the service with too much data. This helps prevent hackers from making "exploratory" requests against your service.
In our tests, Forum XWall successfully blocked our XML attacks in all cases. Some of our tests, ranging from 500 to 5,000 attempts, included invalid data types, SOAP requests with missing elements and nested elements, and null data types.
All of this protection is worthless if you do not know what is going on in the system. XWall includes alerting and monitoring tools that can email you when a specific action occurs, such as too many failed requests from a specific source, as well as save archived log information to your Oracle, MySQL, or DB2 database. The Statistics page provides you with an array of counters for items such as the number of errors, average size of the document, and megabytes processed. For even more specific information about the usage of each policy, the Web Services Monitoring page breaks down each policy into its methods and displays successes and failures.
Most enterprises that are deploying Web services will also want to use Forum's XML schema tightening to protect against SQL injection and command injection, parameter tampering, schema poisoning, and buffer overflows. Unfortunately, these features are not available in XWall. (Forum Systems' flagship product, Sentry, does protect against these attacks but at a much higher price point, starting at $25,000.)
Forum has announced plans to incorporate some schema tightening later this year in XWall.
If you host Web services for public consumption and think your application layer firewall is "good enough," think again. You need a system that looks deep into the SOAP message and enforces policies based on WS-I (Web Services Inspection) and other standards. Forum XWall - whether as a hardware appliance or as a software installation - provides a very granular set of tools for managing your Web services traffic.
I really like the fine level of control available in each policy, and being able to define multiple policies for the same service gives me the flexibility to tailor access to each specific set of circumstances. If you need schema tightening and more control over the XML message, then you will want to look to Sentry instead.