Expert Tips for Securing Web Services

The lead author of one of the most comprehensive books on web services security offers some key tips for designing and deploying security for enterprise-based web services projects. Devs should prep for attacks on their SQL, directory and URL strings. Take a look.

Tags: Web Services, SOAP, Web Services Security, Routing, XML, SOAP Message, Attacks,

The lead author of one of the most comprehensive books on web services security offers some key tips for designing and deploying sercurity for enterprise-based web services projects.

Mark O'Neill, co-author of Web Services Security (McGraw-Hill/Osborne Media) says devs should prep for attacks on their SQL, directory and URL strings. O'Neill is CTO at Vordel, a provider of XML security solutions based in Dublin, and brings a long-term perspective to the issue of web services security. Prior to his work with XML, he worked as an engineer supporting legacy and EDI systems.

Knowing Attacks -- and Guarding Against Them

With this broad legacy-to-web service perspective, O'Neill predicts that as web services mature, developers will need to familiarize themselves with new types of content-centric attacks. Among them:

  • SQL attacks: Inserting SQL statements into web forms in order to force a database to return inappropriate data, or to produce an error that reveals database access information. For web services, this category of attack translates to manipulating data in a SOAP message to include SQL statements that will be interpreted by a back-end database.
  • Directory traversal attacks: Attempts to bypass hyperlinks by directly accessing resources. For example:
    • If a URL is, what happens if is requested?

    • Does a directory called /test/ exist?

    For web services, this category of attack translates to attempting to detect other SOAP services which are not explicitly offered.

  • URL string attacks: Manipulating CGI name/value pairs in the URL string; for example, changing "maxResults=10" to " maxResults=1000" to return more information from a database. For web services, this translates to circumventing the rules on SOAP parameters (for example, if a search SOAP service takes an integer between 1 and 10 as a SOAP parameter, what if the number 1000 is submitted?).

  • While many of these can be avoided by careful programming practices and by cleaning up resources not required on the web server, O'Neill suggests that developers working on B2B web services consider the use of an XML firewall or XML proxy to filter SOAP requests before they reach your application.

    Coming "Clean" on Routing with SOAP

    In Web Services Security, O'Neill notes that "Core elements of web services security are in place [so] SOAP routing does not have to depend on routing information in the SOAP message itself." Routing, he says, can be performed for a number of reasons, including

    1. Scaling a Web Services infrastructure between multiple SOAP servers;
    2. Bridging between two different networking protocols; or
    3. Transforming message content from one format to another.

    These three scenarios extend the security context beyond a single SOAP request/response. To address this issue, O'Neill describes how developers should scope the problem, and then provides examples, a template and even some sample code.

    Scoping the Secure Routing Problem:

    When routing between web services, the requirement for confidentiality can apply from the originator through to the final SOAP endpoint. It may be a requirement that information be kept secret from SOAP intermediaries. There may be a chance that intermediaries may disclose the information, either deliberately or through leaving gaps between one transport-level security session and the next. While the data is decrypted, it is vulnerable.

    Confidentiality for a SOAP transaction should not involve simply chaining instances of confidentiality together, since "SOAP gaps" of unencrypted data are available between each decryption and encryption.

    An Example

    WS-Routing defines how to insert routing information into the header of a SOAP message. This routing information can be considered equivalent to routing tables that operate at lower layers of the OSI stack for routing IP packets.WS-Routing means that one SOAP message may traverse multiple SOAP " hops" between the originator and the endpoint. The systems that implement these hops may have nothing in common apart from the ability to parse and route a SOAP message.

    Sample Code:

    A code sample shows an example of a SOAP message that uses WS-Routing in order to route between web services. (It routes from the originator, via an intermediary, to an endpoint.)
    Detail and more sample code on this web services security topic is available here.

    Inside the book "Web Services Security"

    "Web Services Security" includes perspective, code samples and a plain English explanation of many key topics, including the way details of a web services architecture (SOAP, UDDI, WSDL) will affect your security choices; an in-depth implementation look at WS-Security and its use of XML Signature/XML Encryption, specific background and suggestions for using legacy and web services security tokens (including Kerberos and PKI) and mark-up languages (including SAML, XACML and XKMS).

    In addition, the book has a proactive feel, intended to help the developer build security solutions -- not simply read about options. Practical projects addressed include: