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 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 http://www.example.com/documents/sales.htm, what happens if http://www.example.com/documents/ 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.
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
- Scaling a Web Services infrastructure between multiple SOAP servers;
- Bridging between two different networking protocols; or
- 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.
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.
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:
- WS-Security and the GXA road map, including WS-SecureConversation and WS-Policy;
- Using XKMS for validation and accountability;
- Ensuring data integrity and confidentiality using XML Signature and XML Encryption;
- SAML and XACML for single sign-on authentication and authorization;
- The approach of ebXML to security; .
- Navigating the legal aspects of web services security -- including digital signature laws, privacy issues and application-to-application transactions and others.
O'Neill's co-authors also bring some clout to his perspectives on security. They include Phillip Hallam-Baker, principal scientist at VeriSign; Mike Shema, principal consultant of Foundstone, Inc., and the co-author of The Anti-Hacker Toolkit; Ed Simon, Entrust's XML Security Architect, co-author of the W3C's XML Signature specification and contributor to W3C's XML Encryption; Paul A.Watters, author of the Solaris 8 Administrators Guide; and Patrick Gannon, CEO of OASIS.
Get more info on Web Services Securityhere.