02:15 PM

Review: XML Gateways

Network Computing tested three security devices and, although they all impressed, our top pick edged past the others thanks to stellar performance, flexibility and integration. Find out which one it is.

We cut to the chase of what really matters by awarding 50 percent of our score to the products' protection capabilities--simply, how well they stopped attacks. We divided the protection category into four basic areas:

• Message integrity: We tested a device's ability to encrypt sensitive data and verify signatures on incoming requests. XML Encryption and XML-DigitalSignature are the primary mechanisms of ensuring message integrity in the XML/Web services world. This category also rates the devices' ability to use SSL at the transport layer.

• DoS protection: We examined a product's ability to shield the device and protected back-end services against denial-of-service attacks that use oversized documents, XML-parser exploits and other such mechanisms.

• Content-based defenses: These features stop attacks aimed at back-end services, including SQL injection and external entity attacks.

• Authentication and authorization: This category includes support of Web services-specific protocols, such as WS-Security, to verify users for explicit operations.

We also took into consideration operational and functional management, the security of administrative mechanisms, performance and accuracy under load, and price. Finally, we quizzed each vendor on its methodology for updating devices in response to newly discovered vulnerabilities.

XML Firewall Features
Click to Enlarge

XML Threat Defense

All the products we tested let us secure our XML services against a variety of attacks, but they differ in default settings and control levels. Sarvega's XML Guardian Gateway configures bidirectional schema validation upon policy creation by default. This approach prevents a number of XML attacks without requiring additional configuration--for example, attacks using alternate character sets and SQL injection into non-string-based fields can be stopped by validating the incoming request against the expected schema. Products from both DataPower and Reactivity support schema validation, but it must be added to your policy. Schema validation certainly won't prevent all content-based attacks--loosely written schemas undermine this security mechanism, which is best used to prevent malformed XML from reaching back-end services.

SQL injection attacks are likely the most damaging in terms of information gleaned by attackers and opportunity to destroy data. Out of the box, only Sarvega XML Guardian stopped our SQL attack. We used the other two products' failure here as an opportunity to evaluate DataPower's and Reactivity's methods of updating their devices in the face of "new" vulnerabilities. DataPower's XS40 is based wholly on XSL (Extensible Stylesheet Language); we addressed a new content vulnerability by retrieving and uploading the relevant XSL file. After uploading a new SQL injection pattern file to the XS40, our SQL injection attack no longer succeeded. These products are not proactive in retrieving and updating content filters, as one might expect. Unlike antivirus packages that automatically update filters on a scheduled basis, the products we tested required us to determine whether a new vulnerability had been discovered and then update the content filters manually.

Reactivity, like Sarvega, uses content filtering as its main mechanism for adding protection against new vulnerabilities. Unlike DataPower and Sarvega, however, Reactivity digitally signs new content-filtering files and verifies the signature once a file has been uploaded to its device, before applying it to the system. As with all the participants, we created custom content filters to quickly add protection or functionality. We wrote a new content filter so that Reactivity's 2400 Series XML Security Gateway, which uses regular expression matching, could recognize our "UNION SELECT" SQL attack, then retested. The 2400 properly stopped the probing attack.

All three products tested support standard encryption (XML-ENC) and signatures (XML-DSIG) equally well. To configure the devices, we had to modify our policies to include encryption and signature verification; we accomplished this with ease across all entries. Sarvega and DataPower went further than Reactivity in terms of their products' ability to limit message sizes and incoming XML structure, such as number and depth of nodes, and elements within any given XML document. Controlling both is important in preventing parsing attacks. Only Reactivity's 2400 XML Security Gateway let us place size limitations on the messages it sent to our back-end servers, but it supports this limitation only for non-SOAP messages. We limited message size by manually editing the configuration file and restarting services, but such restrictions were applied to all messages rather than on an operation basis, which is how we'd like to see such filtering accomplished in XML security devices.

2 of 10
Comment  | 
Print  | 
More Insights
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Elite 100 Digital Issue, April 2015
The 27th annual ranking of the leading US users of business technology
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on for the week of April 19, 2015.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.