As Web services become more pervasive, attackers are taking aim. Forum Vulcon, a subscription service offering notification of XML vulnerabilities using a Web services interface, is tracking more than 100 vulnerabilities. This may sound minuscule compared with the thousands of known attacks threatening Web applications and back-end servers, but the danger is that a successful XML-based attack can act as a master key, exposing any number of those application vulnerabilities. Because SOAP (Simple Object Access Protocol) messages carry instructions in protocols that are interpreted as functions to be executed on servers, application-server-specific attacks can be transported inside the XML and passed to the application server, where they wreak havoc.
Because XML is a self-defining format, parser and content-based vulnerabilities are ever evolving and nearly impossible to predict. Therefore, a well-rounded XML security device not only must act as a firewall in the conventional sense--granting or denying access based primarily on Layer 4 information, such as IP address and port--it also must secure back-end services against threats specific to XML and against Web and database servers. This requires XML security to move away from a packet-processing paradigm to the realm of payload analysis.
To see how well the market is meeting this challenge, we asked 11 XML security vendors to participate in rigorous firewall tests in our Green Bay, Wis., NWC Inc. business applications lab. DataPower, Reactivity and Sarvega agreed. Layer 7 initially accepted, but product availability problems led it to pull out. Check Point Software Technologies agreed, then declined. Forum Systems cited scheduling conflicts, while Digital Evolution and Vordel both said they don't consider their products firewalls. Xtradyne was acquired last year by PrismTech and is still positioning its product. Oblix partners with Forum Systems to provide XML security, and after Forum Systems declined, it didn't make sense to include Oblix, which was then acquired by Oracle in March. Actional, which merged with security firm Westbridge last year, declined based on the review focus.
At first, we were frustrated with the low turnout, but the reasons cited point to an industrywide problem: What are these products, and what should they be called? See "The Name Game,", for our take.
Although most conventional firewalls can provide user-based authentication and authorization to services, they're rarely set up to do so; rather, these products control generalized access to services, and their packet-processing mechanisms are not data-aware. XML firewalls, however, must be data-aware to keep unwanted content and users from accessing potentially sensitive services. Although XML over HTTP and even SOAP can be controlled using conventional authentication means, HTTP Basic Auth, for example, SOAP and Web services cognoscenti prefer to use Web services-specific mechanisms, such as WS-Security 1.0, which require authentication and authorization mechanisms to reach into the payload and extract credentials.
For our test scenario, we used NWC Inc.'s Web services deployment, served by IBM WebSphere 6.0 and providing SOAP interfaces to order-entry and tracking functionality. After capturing both requests and responses from all operations, we served them up on our Spirent WebReflector to remove any application bottlenecks. We throttled client traffic back to no more than 2,000 concurrent users, a reasonable number--on the high end for most Web services infrastructures but realistic for an enterprise Web services application. The types of attacks we ran are detailed in "How We Tested XML Firewalls,".