Securing Web services -- More than just Web application security

Michael Hanson, Chief Architect, Reactivity

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

    Requires Free Membership to View

  • 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:

This was first published in September 2003

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.