Along with the new business opportunities created by Web services, IT security personnel now have to contend with vulnerabilities created by Web services data, protocols and frameworks. Like other large, complex software systems, the new infrastructure components are highly prone to vulnerabilities and must be continuously patched and updated. But even greater vulnerabilities may be created inadvertently through exposure of an application's programmatic functions. One solution for securing Web services applications is the XML or Web services firewall, which provides a network-level endpoint with the application-level intelligence to discern good XML from bad.
Unlike traditional Web page interfaces, Web services directly expose core application logic, significantly increasing an organization's risk profile. Take, for example, an otherwise mundane application such as order tracking. It could, through its connection to backend business systems and databases, expose valuable intellectual property or confidential information to attack.
Web services are vulnerable to at least four primary avenues of attack:
- Traditional attacks, such as identity spoofing, information theft and others, now at the XML level.
- Content-borne attacks like SQL insertion and command insertion. Instead of a legitimate query using an order number to request a shipper's tracking number, for example, the XML message could contain an escape code and a malicious SQL command to extract all information from the database, turning a relatively safe order-tracking system into an invitation to disaster.
- XML-level denial-of-service attacks. One of the first was the so-called entity-expansion attack, in which unprivileged local or remote users could use completely "correct" entity declarations in an XML message to wreak havoc upon unprotected XML 1.0 standard compliant parsers, causing them to shut down with an out-of-memory error or use an inordinate amount of processor cycles.
- Vulnerabilities in XML server technologies. SOAP activation frameworks are new, and it is not unreasonable to anticipate that these complex systems will exhibit a range of fairly severe vulnerabilities. Until it was patched, the open source SOAPLite framework for Perl, for example, enabled a remote operator to execute any Perl function on the host, rather than only the designated Web service methods.
While SSL, authentication and other Web application security tools will continue to play an important security role, new methods must be found to deal with these emerging security threats at the application layer. As a response to these new attacks, XML firewalls have emerged to provide a number of important countermeasures against these attacks, including:
- Strong authentication and access control rules, based on new Web services standards being developed by groups like OASIS and WS-I;
- XML structural rules that prevent entity expansion and other attacks based on XML structure;
- XML virus checking -- A set of content heuristics that scan XML message content for signatures of known attacks like SQL insertion;
- XML schema validation at the edge of the network to guard against malformed XML, both malicious and inadvertent; and
- XML denial-of-service protection – Operational controls for protecting against several types of XDoS attacks. The controls include an extremely robust runtime that can determine when particular messages are taking too much time or are getting too many requests and can throttle them back.
Existing security tools and practices such as firewalls and partitioning are still important when deploying Web services, but Web services do move the walls around a bit and change the way the walls have to work. A traditional packet filtering firewall will stop all packets that aren't, say, HTTP, but it can't stop the bad HTTP packets. To do this requires a firewall that works at the application layer and can examine the XML messages, not packets, to determine whether they are good XML messages or not. The XML firewall also externalizes and centralizes application-level security, making the challenging security task of protecting multiple application servers easier, less costly and more manageable.
While patching software and keeping it up to date is important, it is not foolproof, and there will always be some unknown vulnerabilities. This is why it's important to have a stronger wall to push that point of failure further out and provide a uniform, 100% locked-down approach to the network.
About the author
Michael Hanson is the lead architect of Reactivity's secure networking products. Michael represents Reactivity in the WS-I standards organization and is a lead contributor for security and testing issues. Michael holds Bachelor's and Master's degrees in Computer Science from Stanford University.
For more information on this topic, visit these resources:
