XML Developer Tip
XML messaging security under the gun
Ed Tittel
Leigh Dodds, author of the XML-Deviant column at xml.com puts forward some interesting summary and analysis from the XML developer community in a recent column entitled "In a Lather About Security." What he has to say is important and potentially serious enough to be worth a brief recap here, but those of you who are interested in more detail should not only read his story, but follow his links to the original source materials as well.
SOAP is the Simple Object Access Protocol, an XML-based technology designed to pass messages between applications across a network. RPC stands for Remote Procedure Call, and represents a set of programmatic interfaces to let local applications request and reply to network access and services "as if they were local." REST stands for Representational State Transfer, a Web oriented set of transaction services that defines its own mechanisms to model and handle networked transactions of all kinds.
As Dodd's article points out, there's a raging debate in the XML developer community right now that while SOAP-RPC is a powerful and all-too-usable technology to bolt applications and services together across a network, it's fraught with potential security issues that could be problematic in many, many scary ways. The real kicker is that using SOAP-RPC essentially hides all kinds of potentially classified or confidential information inside the standard Web communications protocol, HTTP. This not only makes it possible to slip SOAP-RPC traffic through corporate firewalls (normally deliberately open for Web traffic on port 80) but lets developers bypass or ignore security safeguards at the same time.
REST on the other hand takes a much more formal and explicit notion of transaction modeling into account when modeling and implementing networked communications. This makes it more straightforward and possible to build security concerns in from the ground up, and implies that this approach has a better chance of being secure. But like SOAP-RPC, while REST has the potential to offer enhanced security, it has no absolute requirements that security considerations be addressed in building and implementing transaction handling systems.
Dodds reports that Michael Brennan, of Allegis.com, says that issues likely to cause security problems in Web services are the same issues that cause such problems already (the following list is paraphrased from Brennan's original e-mail message). They include:
- Some developers who accept incoming data that arrives from the network at "face value" (without checks) thus opening themselves to attack, contamination, and compromise;
- Some developers who still believe in "security through obscurity" (a na? assumption that if a service isn't advertised, it won't be noticed or attacked);
- Developers who do not write code that takes precautions against sniffing or snooping (electronic eavesdropping), when insecure channels or methods are used for network communications);
- Vendors who stress features and "first-to-market" in their products, without paying proper heed to security, to their own and their customers' detriment;
- Vendors who promise to handle security matters for developers without putting their products through proper checks or testing;
- Those who believe that simply installing and configuring a firewall confers absolute network security. Because of HTTP tunneling issues and other ways to make end runs through firewalls, this is sadly mistaken.
Ultimately, the real solution to these problems will come from training software architects and developers to "think security" from the very inception of their designs. It also means making security audits and testing part of standard software testing methodologies, and making sure that security issues are addressed when consumers go to vendors or service providers to purchase services, products, or information. Although these concerns address more than XML, they must become part and parcel of the way services are conceived, developed, and delivered. Because XML is key to development of future Web services, this debate must continue and be heeded within the XML community.
Have questions, comments, or feedback about this or other XML-related topics? Please e-mail me care of tips@searchwebservices.com. I'm always glad to hear from my readers.
About the Author
Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of LeapIt.com. LANWrights offers training, writing, and consulting services on Internet, networking, and Web topics (including XML and XHTML), plus various IT certifications (Microsoft, Sun/Java, and Prosoft/CIW).
For More Information
- Need help with the latest industry acronyms and terms? Visit our helpful Glossary.
- Visit our Best Web Links for the best editor-selected XML resources on the Web.
- Post your technical questions, or help your peers in our Enterprise Developer Forums.
- Ask the Experts! Our Web Services, SOAP, WSDL, XML, .NET, Java and EAI gurus answer your toughest questions.
